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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document provides the technical realisation for the combination of Circuit Switched calls and IM sessions 
when using them simultaneously between the same two users. 

The present document describes the use of CS and IM services in combination, using the existing procedures that have 
been defined for CS and IMS. It includes the necessary function as adding an IM session to an ongoing CS call, adding 
a CS call to an ongoing IM session, supplementary services as they relate to CSICS and supporting capability exchange. 

The present document is applicable to UE and Application Servers providing for the combination of Circuit Switched 
calls and IM sessions. 
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ISDN interworking". 

Editor's note: The above document cannot be formally referenced until it is published as an RFC. 



3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions are given in 3GPP TS 22.279 [2]. 

Combinational Service 
Combinational call 
Combinational Session 
CSICS capable UE 

For the purposes of the present document, the following terms and definitions are given in 3GPP TS 23.279 [3]. 

CSI session 

Multimedia IMS session 
CSI origination 
CSI termination 
IMS origination 
IMS termination 

For the purposes of the present document, the following terms and definitions given in 3GPP TR 21.905 [1] apply: 

Universal Subscriber Identity Module (USIM) 
User Equipment (UE) 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 33.203 [12] apply: 

IM Subscriber Identity Module (ISIM) 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations defined in 3GPP TR 21.905 [1] and the following 
abbreviations apply: 

CSICS Circuit Switched IMS Combinational Service 

4 Common capability information and identifiers for 
CS-first and IMS-first scenarios 

4.1 UE capability exchange - overview 

The terminal capabilities that can be exchanged are: 

a) Media types which can be supported as IMS media streams (i.e. media component definitions of IM sessions); 

b) Media format parameters for supported IMS media types (codecs, media file formats etc.); 

c) MSISDN and preferred SIP URI or tel URI for the UE sending the UE capability information; 

d) Whether the terminal is capable combining an IM session with either CS-Video telephony, CS-Voice, or both; 

e) MMS version that is supported; 
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f) Support for other IMS based capabilities and/or services e.g. PoC; and 

g) Personal ME Identifier to identify which of the user"s MEs the UE capability information is related to. 

h) UE capability version, which may be used to identify the current capabilities of a terminal to indicate capability 
update. 

i) The IM Status, which indicates the IMS capability and registration status of the sending UE. 

3GPP TS 26.141 [13] specifies the 3GPP recommended media formats and codecs which can be reflected in the SDP 
used by the CUA. 

4.2 Personal ME identifier 

A specific ME of the user shall be identified by a personal ME identifier, which has the syntax PMI-XXXX. The part 
"XXXX" shall be a random value, as defined in 3GPP TS 24.008 [4] subclause 2.1.1, in the range from hexadecimal 
0000 to hexadecimal FFFF generated by the CUA. The personal ME identifier shall be stored by the UE and can be 
changed to ensure that two or more of the user's MEs do not have the same personal ME identifier. 

At CS call setup, the MSISDN distinguishes a user and the personal ME identifier distinguishes one ME among those 
belonging to that user. In the IMS, a public user identity distinguishes a user and the personal ME identifier 
distinguishes one ME among those belonging to that user. 

The personal ME identifier may be exchanged during: 

UE capability information exchange; 

IM session set up; and 

CS call set up. 



4.3 UE capability version 



The UE capability version is used to identify the current UE"s version of capabilities and has the syntax UCV-XX. The 
part 'XX' shall be a value in the range from hexadecimal 00 to hexadecimal FF generated by the CUA, and based on the 
set of capabilities. The UE capability version shall be changed to another value whenever the CUA changes its 
capabilities. 

The UE capability version may be exchanged during: 

UE capability information exchange; 

IM session set up, and 

CS call set up. 

4.4 Radio environment information 

The radio environment information is used to indicate whether the terminal is in a radio environment at CS call 
setup that supports simultaneous use of CS and PS services. 

The radio environment information may be exchanged during CS call setup only. 

4.5 IIVI Status 

The IM Status is exchanged at CS call setup only. The IM Status is only valid for the duration of the CS call. 

The IM Status is an indication of the IMS capability and registration status of the UE that provides this indication. The 
IM Status, if provided, shall indicate the UE as either:- 
- not capable of IM subsystem registration 
IM subsystem registered 
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IM subsystem capable and willing to register to IM subsystem 
IM subsystem capable but will not register to IM susbsystem 

The IM Status of the UE that provides the IM Status can be used by the receiving CUA in its decision to perform an 
IMS registration if allowed by user's preference (and if the receiving UE is not already IMS registered). 

The provision of the IM Status is optional. 



Common procedures for CS-first and IMS-first 
scenarios 



5.1 Registration of UE capabilities 



The CUA may include a media feature tag in the Contact header of a REGISTER request, in accordance with 

RFC 3840 [6]. The media feature-tags applicable for CSI are g.3gpp.cs-voice, g.3gpp.cs-video, or both values. These 

media feature tags are further described in annex A. 

5.2 Criteria for initiating capability exchange 

An OPTIONS request should be sent from the UE to the remote UE in the following cases: 

a) when the UE is in a CS call with the remote UE; and 

the received radio environment information indicates that the remote UE and remote radio environment is 
capable of handling PS and CS domain simultaneously; 

the received MSISDN plus personal ME identifier plus UE capability version does not match any 
combination in use by the UE to cache capabilities; and 

the received IMS status is "MS is IM subsystem registered" or "MS is IM subsystem capable and willing to 
register to IM subsystem". 

b) when the UE is in an IM session with the remote UE and the received INVITE request includes UE capability 
version plus public user identity plus personal ME identifier that does not match any combination in use by the 
UE to cache capabilities. 

NOTE 1 : For a CSI call where the CS call is established first, the OPTIONS request can only be sent when the PS 
domain is available. The PS domain can either be available already when the CS call is set-up or at a later 
instant due to changed radio condition. 

c) when the UE capabilities have been significantly upgraded; or 

NOTE 2: A significant upgrade of UE capabilities is when an UE has been upgraded with e.g. video capability or 
supports a new service. 

d) when a UE receives an OPTIONS request from a remote UE and there is no ongoing (or recently finished) 
capability exchange initiated by the UE. 

NOTE 3: The OPTIONS request can be sent as a standalone transaction or as a part of a session. 

Information specific to capability exchange with a CS-call already established is covered in subclause 7.3.1.2. 
Information specific to capability exchange with an IM session already established is covered in subclause 6.3.1.2. 

5.3 Criteria for responding to a capability exchange request 

The end-user or application shall give its approval for the UE capabilities to be included in response to a capability 
exchange request. 
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5.4 Exchange of radio environment information and IIVI Status 

A UE may send information about its current radio environment and its IM Status during CS Call set-up. If the UE finds 
that the remote UE's IM Status indicates the remote UE is either IM subsystem registered or IM subsystem capable and 
willing to register to IM subsystem and its current radio environment supports simultaneous CS and PS services, then if 
allowed by the user"s preference the UE should attempt an IMS registration (if the UE is not already IMS registered). 

The information exchanged during the call establishment is valid for the duration of the CS call. 

5.5 Storage of capabilities in the UE 

The terminal capabilities of other UEs are stored by the requesting UE. This stored information shall be valid until 
ISIM/USIM is removed or until an update of the terminal capabilities occurs according to subclause 5.2. Stored 
information shall not be deleted when the UE is switched off. 



6 Combining a CS call with an existing IM session 

6.1 Introduction 

(void) 

6.2 Functional entities 

6.2.1 User equipment 

A UE shall implement the role of a CUA as specified in subclause 6.3.1. 

6.2.2 Application server (AS) 

An application server may be included for a CSI call. However, no specific CSI role is assigned to it. 

6.3 Roles 

6.3.1 CSI user agent (CUA) 

6.3.1.1 General 

In addition to the procedures specified in subclause 6.3.1, the CUA shall support the procedures specified in 
3GPP TS 24.229 [5] appropriate to the functional entity in which the CUA is implemented. 

6.3.1 .2 Exchange of UE capability information - IM session first scenario 

When a CUA wants to exchange capabilities with the remote party, the CUA originating the OPTIONS request shall 
apply the procedure as specified in 3GPP TS 24.229 [5] with the following additions: 

a) The CUA shall in the Request URI: 

include the URI received in the P-Asserted-Identity header from the remote CUA; or if that is not available: 

include a tel URI corresponding to the MSISDN intended for the CS call set up; or 

include a SIP URI associated with the remote user available in the CUA. 
NOTE 1 : The MSISDN can only be included as a tel URI if it is in international format. 
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NOTE 2: If no SIP URI or tel URI in accordance with above is available the CUA cannot initiate the OPTIONS 
request. 

NOTE 3: The OPTIONS request can also be sent as a part of a session. The request URI needs to be set in 
accordance with TS 24.229 [5] in this case. 

b) The CUA shall in the P-Preferred-Identity header either include: 

- preferably the MSISDN of an assumed registered tel URI of the CUA; or 
an assumed registered SIP URI associated with the CUA. 

c) The CUA shall in the Accept-Contact header include media feature tag(s) with the value(s) "+g.3gpp.cs-voice" 
or "+g.3gpp.cs-video" or both, marked as explicit. 

d) The CUA may in the User- Agent header include the personal ME identifier and the UE capability version. Both, 
the personal ME identifier and the UE capability version, shall be present or neither of them. 

The CUA answering with a 200 (OK) response to the OPTIONS request shall apply the procedure as specified in 
3GPP TS 24.229 [5] with the following additions: 

a) The CUA shall in the Contact header include media feature tag(s) with the value(s) "+g.3gpp.cs-voice", 
"+g.3gpp.cs-video" or both. The CUA shall include in the Contact header the SIP-URI and, if available the tel 
URI that can be used to establish a CSI call. 

NOTE 4: The indicated tel URI corresponds to the MSISDN intended for the CS call setup. 

b) The CUA may in the Server header include the personal ME identifier and UE capability version. Both, the 
personal ME identifier and the UE capability version, shall be present or neither of them. 

Upon the receipt of the 200 (OK) response the CUA acts in accordance with 3GPP TS 24.229 [5]. In addition, the CUA 
may locally update the UE capability information, the URIs associated with the remote CUA and the personal ME 
identifier of the remote CUA. 

6.3.1 .3 Session set-up - originating case 

When the originating CUA wants to establish an IM session in combination with a CS call, the CUA shall apply the 
session initiation procedure specified in 3GPP TS 24.229 [5] with the following additions: 

a) The CUA shall in the Request-URI in the initial request either include: 

1) a tel URI that is the MSISDN intended for CS call set up; or 

2) a SIP-URI associated with the remote user available in the CUA. 

NOTE: The MSISDN can only be included as a tel URI if it is in the international format. 

b) The CUA shall in the P-Preferred-Identity header in the initial request include an assumed registered tel URI 
corresponding to the MSISDN of the CUA. 

c) The CUA shall in the Accept-Contact header in the initial request include media feature tag(s) with the values 
"H-g.3gpp.cs-voice", "H-g.3gpp.cs-video" or both, marked as explicit. 

d) The Contact header shall include media feature tag(s) with the value(s) "H-g.3gpp.cs-voice",''+g.3gpp.cs-video" 
or both. 

e) The CUA may in the User- Agent header include the personal ME identifier and UE capability version. Both, the 
personal ME identifier and the UE capability version, shall be present or neither of them. 

If the response includes a personal ME identifier and a UE capability version and the combination of public user 
identity plus personal ME identifier plus UE capability version of the terminating UE is known to the CUA, the CUA 
may indicate capability information of the terminating UE to the user via the MMI. 
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6.3.1 .4 Session set-up - terminating case 

When the terminating CUA receives an initial request, the terminating CUA shall apply the procedures as specified in 
3GPP TS 24.229 [5]. The Contact header shall include media feature tag(s) with the value(s) "+g.3gpp.cs-voice", 
"+g.3gpp.cs-video" or both in the response(s), in accordance with RFC 3840 [6]. The UE may include the personal ME 
identifier and UE capability version in the Server header in the responses. Both, the personal ME identifier and the UE 
capability version, shall be present or neither of them. 

If the request includes a personal ME identifier and a UE capability version and the combination of public user identity 
plus personal ME identifier of the originating UE is known to the CUA, the CUA may indicate capability information 
of the originating UE to the user via the MMI. 

6.3.1 .5 CS call set-up - originating case 

When the originating CUA wants to add the CS part of a CSICS call, it shall set up the call in accordance with 
3GPP TS 24.008 [4] with the following additions: 

a) The CUA may include the radio environment information and the IM Status, the personal ME identifier and UE 
capability version in the user-user information (as defined in 3GPP TS 24.008 [4] Annex O) in the SETUP 
Message. Both, the personal ME identifier and the UE capability version, shall be present or neither of them. The 
handling of the user-user information element shall be in accordance with 3GPP TS 24.087 [9]. 

NOTE 1 : If the CUA does not support the user-to-user 1 supplementary service, in accordance with 

3GPP TS 22.087 [8] the radio environment information, the IM Status, the personal ME identity, and the 
UE capability version: 

will not be sent to the remote CUA, 

will be ignored if provided by the remote CUA. 

b) The CUA shall include in the called party BCD number either: 

an E.164 number as included in the P-Asserted-Identity header that was received during IM session 
establishment; or 

if this is not possible, the MSISDN of the remote user stored in UE. 

NOTE 2: It is assumed that the originating CUA uses the COLP supplementary service, in accordance with 
3GPP TS 22.081 [7] and UUS service 1, in accordance with 3GPP TS 22.087 [8]. The CLIR 
supplementary service in accordance with 3GPP TS 22.081 [7] is not in use in the originating CUA. 

If the connected number received in the CONNECT message differs from the MSISDN number used in the SETUP 
message, the actions to be taken by the CUA are implementation dependent. 

6.3.1 .6 CS call set-up - terminating case 

When the terminating CUA receives a CS call, the CUA shall check if there any ongoing IM sessions, which were 
initiated with a request that included an Accept-Contact header with media feature tag(s) with the value(s)"H-g.3gpp.cs- 
voice", "H-g.3gpp.cs-video" or both. 

If there are ongoing IM sessions, which were initiated with a request that included an Accept-Contact header 
with media feature tag(s) with the values(s)"H-g.3gpp.cs-voice, "H-g.3gpp.cs-video" or both and if the received 
Calling Party BCD number corresponds to an entry in the P-Asserted-Identity header in an ongoing IM session, 
the CUA shall set up the call in accordance with 3GPP TS 24.008 [4]. The CUA may include the user-user 
information element with the radio environment information, the IM Status, personal ME identifier (as defined in 
3GPP TS 24.008 [4] Annex O) and UE capability version in the CONNECT message, in accordance with 
3GPP TS 24.087 [9]. Both, the personal ME identifier and the UE capability version, shall be present or neither 
of them. 

Otherwise, the CUA shall set up the call in accordance with subclause 7.3.1.6. 

NOTE 1 : If the CUA does not support the user-to-user 1 supplementary service, in accordance with 

3GPP TS 22.087 [8] the radio environment information, the IM Status, the personal ME identifier and the 
UE capability version: 
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will not be sent to the remote CD A, 

will be ignored if provided by the remote CUA. 

NOTE 2 It is assumed that the terminating CUA uses the CLIP supplementary service, in accordance with 
3GPP TS 22.081 [7] and UUS service 1, in accordance with 3GPP TS 22.087 [8] The COLR 
supplementary service in accordance with 3GPP TS 22.081 [7] is not in use in the terminating CUA. 

NOTE 3: If the CUA does not support the user-to-user 1 supplementary service, in accordance with 

3GPP TS 22.087 [8] the radio environment information, the IM Status, the personal ME identifier and UE 
capability version will not be sent to the remote CUA. 

6.3.1 .7 SDP exchange - UE capability information exchange 

The CUA shall act in accordance with 3GPP TS 24.229 [5] when the CUA exchanges its capabilities with the remote 
CUA. 

The following information may be included: 

a) Media types which can be supported as IMS media streams (i.e. media component definitions of IM sessions). 

b) Media format parameters for supported IMS media types (codecs, media file formats etc.). 
NOTE: The media and codecs used for the CS call are not included in the SDP. 

6.3.1 .8 SDP offer answer - originating case 

When a CUA wants to create a CSI communication, the CUA shall populate the SDP as specified in subclause 6.1 in 
3GPPTS 24.229 [5]. 

6.3.1 .9 SDP offer answer - terminating case 

When a CUA wants to participate in a CSI communication, the CUA shall populate the SDP as specified in 
subclause 6.1 in 3GPP TS 24.229 [5]. 



7 Combining an IIVI session with an existing CS call 

7.1 Introduction 

(void) 

7.2 Functional entities 

7.2.1 User equipment 

A UE shall implement the role of a CUA as specified in subclause 7.3.1. 

7.2.2 Application server (AS) 

An application server may be included for a CSI call. However, no specific CSI role is assigned to it. 
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7.3 Roles 

7.3.1 CSI user agent (CUA) 

7.3.1.1 General 

In addition to the procedures specified in subclause 7.3.1 of this document, the CUA shall support the procedures 
specified in 3GPP TS 24.229 [5] appropriate to the functional entity in which the CUA is implemented. 

7.3.1 .2 Exchange of UE capability information - CS first scenario 

When the CUA wants to exchange capabilities with the remote party, the CUA originating the OPTIONS request shall 
apply the procedure as specified in3GPP TS 24.229 [5] with the following additions: 

a) The CUA shall in the Request URI include one of the following: 

a URI, as received in P-Asserted-Identity header from the remote CUA during the terminal capability 
information exchange procedure; or, if this is not available; 

a tel URI consisting of the Connected Number information element or the Calling Party BCD number 
received during establishment of the existing CS call, or the MSISDN used for the CS call set-up ( the Called 
Party BCD Number); or 

a SIP URI associated with the remote user stored in the CUA. 

NOTE 1 : The MSISDN can only be included as a tel URI if it is in the international format. 

NOTE 2: If no SIP URI or tel URI in accordance with above is available the CUA cannot initiate the OPTIONS 
request. 

b) The CUA shall in the P-Preferred-Identity header either include: 

the MSISDN of the CUA as an assumed registered tel URI; or 
an assumed registered SIP URI associated with the CUA. 

c) The CUA shall in the Accept-Contact header include media feature tag(s) with the values(s) "+g.3gpp.cs-voice", 
"+g.3gpp.cs-video" or both marked as explicit. 

d) The CUA may in the User- Agent header include the personal ME identifier and the UE capability version. Both, 
the personal ME identifier and the UE capability version, shall be present or neither of them. 

The CUA answering with a 200 (OK) response to the OPTIONS request shall apply the procedure as specified in 
3GPP TS 24.229 [5] with the following additions: 

a) The CUA shall in the Contact header include media feature tag(s) with the values(s) "H-g.3gpp.cs-voice", 
"H-g.3gpp.cs-video" or both. The CUA shall include in the Contact header the SIP-URI and, if available the tel 
URI that can be used to establish a CSI call. 

NOTE 3: The indicated tel URI corresponds to the MSISDN intended for the CS call setup. 

b) The CUA may in the Server header include the personal ME identifier and the UE capability version. Both, the 
personal ME identifier and the UE capability version, shall be present or neither of them. 

Upon the receipt of the 200 (OK) response, the CUA acts in accordance with 3GPP TS 24.229 [5]. In addition, the CUA 
may locally update the UE capability information for the remote user, the URIs associated with the remote CUA and the 
personal ME identifier of the remote CUA. 

7.3.1 .3 Session set-up - originating case 

When the originating CUA wants to add an IM session to a CS call, it shall apply the call initiation procedure specified 
in 3GPP TS 24.229 [5] with the following additions: 
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a) The CUA shall in the Request URI in the initial request either include: 

1) the URI, as received in P- Asserted Identity header from the terminating CUA during the terminal capability 
information exchange procedure; or if this is not available 

2) a tel URI that either is: 

the connected number information element, received during establishment of the existing CS call, and if 
this is not available the MSISDN used for the CS call set-up (the used Called Party BCD Number); or 

the Calling Party BCD number information element, received during establishment of the existing CS 
call. 

b) The CUA shall in the P-Preferred Identity header in the initial request include an assumed registered tel URI 
corresponding to the MSISDN of the CUA. 

c) The CUA shall in the Accept-Contact header in the initial request include media feature tag(s) with the value(s) 
'+g.3gpp.cs-voice', a '+g.3gpp.cs-video' or both, marked as explicit. 

d) The Contact header shall include media feature tag(s) with the value(s) "+g.3gpp.cs-voice","+g.3gpp.cs-video" 
or both. 

e) The CUA may in the User- Agent header include the personal ME identifier and the UE capability version. Both, 
the personal ME identifier and the UE capability version, shall be present or neither of them. 

NOTE 1 : If privacy is indicated it is not possible to correlate the CS call and the IM session. 

7.3.1 .4 Session set-up - terminating case 

When the terminating CUA receives an initial request for an IM session, the terminating CUA shall apply the 
procedures as specified in 3GPP TS 24.229 [5] with the following additions: 

a) If the Accept-Contact header in the INVITE request includes a media feature tag(s) with the 
value(s)"H-g.3gpp.cs-voice", "H-g.3gpp.cs-video" or both, the CUA shall check if one of the identities in the P- 
Asserted-Identity header matches the received Calling Party BCD number information element or Connected 
number information element received for an ongoing CS call. If there is a match, a CSICS call is established. 

Otherwise, the CUA shall not consider this a CSI call/session. 

b) The Contact header shall include media feature tag(s) with the value(s) "H-g.3gpp.cs-voice", "H-g.3gpp.cs-video" 
or both in the response(s), in accordance with RFC 3840 [6]. 

c) The UE may include the personal ME identifier and the UE capability version in the Server header in the 
responses. Both, the personal ME identifier and the UE capability version, shall be present or neither of them. 

7.3.1 .5 CS call set-up - originating case 

When the originating CUA wants to set up a CS call in combination with an IM Session, the CUA shall set up the call 
in accordance with 3GPP TS 24.008 [4] with the following additions: 

a) The SETUP message may include the user-user information element, which can include the radio environment 
information, the IM Status, the personal ME identifier and the UE capability version as specified in 
3GPP TS 24.008 [4] Annex O. Both, the personal ME identifier and the UE capability version, shall be present 
or neither of them. The handling of the user-user information element shall be in accordance with 
3GPPTS 24.087 [9]. 

If the CONNECT message includes a personal ME identifier and UE capability version and the combination of 
MSISDN plus personal ME identifier plus UE capability version of the terminating UE is known to the CUA, the CUA 
may indicate already available capability information of the terminating UE to the user via the MMI. If originating UE 
finds that terminating UE and its current radio environment supports simultaneous CS and PS services and terminating 
UE's IM Status indicates the remote UE is either IM subsystem registered or IM subsystem capable and willing to 
register to IM subsystem, then if allowed by the user"s preference originating UE should attempt an IMS registration (if 
the UE is not already IMS registered). 
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NOTE 1 : If the CUA does not support the user-to-user 1 supplementary service, in accordance with 

3GPP TS 22.087 [8] the radio environment information, the IM Status, the personal ME identifier and the 
UE capability version: 

will not be sent to the remote CUA, 

will be ignored if provided by the remote CUA. 

NOTE 2: It is assumed that the originating CUA uses COLP supplementary service, in accordance with 
3GPP TS 22.081 [7] and UUS service 1, in accordance with 3GPP TS 22.087 [8] The CLIR 
supplementary service in accordance with 3GPP TS 22.08 1 [7] is not in use in the originating CUA. 

7.3.1 .6 CS call set-up - terminating case 

When the terminating CUA receives a CS call: 

a) the CUA shall set up the call in accordance with 3GPP TS 24.008 [4] and may include the user to user 
information element in the CONNECT message with the radio environment information, the IM Status, the 
personal ME identifier and the UE capability version as defined in 3GPP TS 24.008 [4] Annex O. Both, the 
personal ME identifier and the UE capability version, shall be present or neither of them. The handling of the 
user-user information element shall be in accordance with 3GPP TS 22.087 [8]. 

If the SETUP message includes a personal ME identifier and UE capability version and the combination of MSISDN 
plus personal ME identifier plus UE capability version of the originating UE is known to the CUA, the CUA may 
indicate already available capability information of the originating UE to the user via the MMI. If terminating UE finds 
that originating UE and its current radio environment supports simultaneous CS and PS services and originating UE's 
IM Status indicates the remote UE is either IM subsystem registered or IM subsystem capable and willing to register to 
IM subsystem, then if allowed by the user"s preference terminating UE should attempt an IMS registration (if the UE is 
not already IMS registered). 

NOTE 1 : If the CUA does not support the user-to-user 1 supplementary service, in accordance with 

3GPP TS 24.087 [9] the radio environment information, the IM Status, the personal ME identifier and the 
UE capability version: 

will not be sent to the remote CUA 

will be ignored if provided by the remote CUA. 

NOTE 2: It is assumed that the terminating CUA uses the CLIP supplementary service, in accordance with 3GPP 
TS 22.081 [7] and UUS service 1, in accordance with 3GPP TS 22.087 [8]. The COLR supplementary 
service in accordance with 3GPP TS 22.081 [7] is not in use in the terminating CUA. 

7.3.1 .7 SDP exchange - UE capability information exchange 

The CUA shall act in accordance with subclause 6.3.1.7. 

7.3.1 .8 SDP offer-answer - originating case 

The CUA shall act in accordance with subclause 6.3.1.8. 

7.3.1 .9 SDP offer-answer - terminating case 

The CUA shall act in accordance with subclause 6.3.1.9. 
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8 Interaction with supplementary services 

8.1 Roles 

8.1.1 CSI user agent (CUA) 

No protocol interactions for supplementary services are identified. 
NOTE: Service interactions are specified in 3GPP TS 23.279 [3]. 

8.1 .2 CSI application server (CSI AS) 

8.1.2.1 Introduction 

Other than the interactions to supplementary services described below, no further interactions to other supplementary 
services have been identified. 

8.1 .2.2 Call Forwarding and Call Barring 

The determination that Call Fowarding is being applied to terminating CUA or that Call Barring has been applied to the 
terminating CUA and the subsequent behaviour of the CSI AS is given in subclause 9.3.3.5. 

8.2.1.3 Call Completion 

If the CSI AS receives indications that the terminating CUA has applied call hold or call retrival, the CSI AS shall 
perform corresponding session modification toward the originating UE. 



IMS origination and CSI termination 



9.1 Introduction 

This subclause describes the detailed procedures for establishing sessions from UEs that use IMS origination to UEs 
that use CSI termination. 

NOTE: The IMS origination and CSI termination are specific session establishment scenarios defined in TS 
23.279 [3]. When a UE is considered to use IMS origination and when a UE is considered to use CSI 
termination is defined in subclause 9.2.1 of TS 23.279 [3]. 

9.2 Functional entities 
9.2.1 User equipment 

For establishing sessions with IMS origination and CSI termination, two different UEs are involved. 

1) The UE that uses CSI termination, which terminates sessions by receiving real time media over the CS 
domain. This UE implements the role of CUA as specified in subclause 6.3.1 and subclause 7.3.1. 

2) The UE that uses IMS origination, which originates sessions by transmitting real time and non-real time 
media over an IP-CAN. 
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9.2.2 Application server (AS) 

For supporting the control functionality required to handle sessions with IMS origination and CSI termination an 
application server shall implement the role of CSI AS as defined in subclause 9.3.3. 

9.2.3 MGCF 

No specific role in support of provision of CSI terminating session has been identified for the MGCF. In this version of 
this document, any CSI capability related information if provided to the MGCF will not be interworked by the MGCF. 

9.3 Roles 

9.3.1 Void 

9.3.2 CSI UA (CUA) 

The UE that uses CSI termination implements the role of CUA as specified in subclause 6.3.1 and subclause 7.3.1 with 
no additional requirements. 

NOTE: For proper handling and delivery of CSI terminating sessions, a CUA needs to include the media feature 
tags applicable for CSI in the Contact header when performing the registration procedure. 

9.3.3 CSI AS 

9.3.3.1 General 

The CSI AS shall support the procedure for the multimedia session splitting, modifying, combining and releasing. 

To support a CSI session between a UE in IMS only mode and a CSI capable UE (CUA), the CSI AS shall support 
capability exchange with the CUA in the terminating CS domain on behalf of the CUA in the originating IM CN 
subsystem, when the CSI AS has determined that the network supports the required CSI functionality. 

The CSI AS can use the media feature tags (e.g. g.3gpp.cs-voice and g.3gpp.cs-video) obtained from the terminating 
CUA to perform termination logic. 

If the media feature tags indicate that the CUA has both voice and video capabilities and that CSI AS knows that video 
interworking to the CS domain is supported, then the CSI AS can use the CS domain to terminate any realtime voice 
and video sessions to the CUA. However the IM CN subsystem can also be used for the video component of the real 
time conversation. 

NOTE 1 : The knowledge that the IM CN subsystem supports video interworking to the CS domain is configured in 
the CSI AS. 

The procedure of multimedia session splitting is specified in the subclause 9.3.3.3. 

NOTE 2: The CSI AS obtains the media feature tags of the terminating CUA from the reg-event package. 

9.3.3.2 Retrieval of public user identity information 

The CSI AS can obtain information about the public user identities of the CUA by using the reg event package as 
specified in 3GPP TS 24.229 [5], or via the Sh interface as specified in 3GGP TS 29.328 [16]. 

The information about the public user identities can also be provisioned in the CSI AS. 

NOTE: A third party REGISTER request received by the CSI AS can be triggered by a CUA including in the 
Contact header of the REGISTER request the media feature tag value(s) of "+g.3gpp.cs-voice"and 
"+g.3gpp.cs-video"or both. 
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9.3.3.3 Session Splitting towards terminating CUA 

9.3.3.3.1 General 

When the CSI AS receives at SIP INVITE request including the SDP media descriptions for both voice media and non- 
voice media(e.g. MSRP) from the originating UE, the CSI AS shall check if the received dialog identifier in the request 
matches a dialog identifier for an ongoing session in the CSI AS: 

1) if there is no match, the CSI AS performs the session splitting procedure as follows: 

a) for the non-voice media, the CSI AS shall initiate the new SIP INVITE request requesting the same non- 
voice media as received in the incoming INVITE request towards the CUA via IM CN subsystem as per 
subclause 9.3.3.3.3; and 

b) for the voice media, the CSI AS shall initiate the new SIP INVITE request requesting the same voice media 
as received in the incoming INVITE request towards the CUA via CS domain through the MGCF as per 
subclause 9.3.3.3.2. 

2) if there is a match, the CSI AS shall act as per subclause 9.3.3.4.3. 

When the CSI AS receives the SIP INVITE request including the SDP media description from the originating UE for 
voice media only, the CSI AS shall check if the dialog identifier in the request matches a diolog identifier for an 
ongoing session in the CSI AS;. 

1) if there is no match, the CSI AS shall follow the procedure in subclause 9.3.3.3.2; or 

2) otherwise the CSI AS shall follow the procedures as specified in subcaluse 9.3.3.4.2. 

When the CSI AS receives the SIP INVITE request including the SDP media description from the originating UE for 
non-voice media only, the CSI AS shall check if the dialog identifier in the request matches a dialog identifier for an 
ongoing session in the CSI AS: 

1) if there is no match, the CSI AS shall follow the subclause 9.3.3.3.3; or 

2) otherwise the CSI AS shall follow the subcaluse 9.3.3.4.1. 

For the standalone SIP request and the SIP request initiating a new dialog other than the SIP INVITE request, the CSI 
AS shall follow subclause 5.7.5 of 3GPP TS 24.229[5] without splitting. 

9.3.3.3.2 Call Initiation towards the CS domain 

When the CSI AS receives an initial SIP INVITE request that requests an IMS session with voice media, the CSI AS 
shall perform the third party call control, as specified 5.7.5 of 3GPP TS 24.229[5] including the following: 

1) The CSI AS creates the SIP INVITE request setting the Request-URI and To header to a Tel-URI which is an 
alias of the SIP-URI which is included in the received SIP INVITE request; 

NOTE: The CSI AS maps between SIP-URI and Tel-URI from information provided by the HSS about alias 
URIs of the registered identity, as specified in 3GPP TS 29.328[16]. 

2) The CSI AS adds the address of BGCF in the Route header to be located behind of the address of S-CSCF; 

3) The CSI AS populates the SDP with the voice media parameters which were included in the SIP INVITE request 
from the originating UE; and 

4) The CSI AS sends the SIP INVITE request towards the S-CSCF for further routeing. 

If the CSI AS does not take any action for the received SIP INVITE request, it shall apply the procedure described in 
subclause 5.7.4 of 3GPP TS 24.229 [5]. 

9.3.3.3.3 Session Initiation towards the IM CN subsystem 

When the CSI AS initiates a session towards the CUA for a non-voice media the CSI AS shall; 
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1) operate as an application server performing 3' party call control acting as a routing B2BUA, as specified in 
subclause 5.7.5 of 3GPP TS 24.229 [5] for this request and all future requests and in the same dialog; 

2) set the Request-URI and the To header field to the SIP-URI for the CUA in the outgoing SIP INVITE request; 

3) populate the SDP with the non-voice media parameters which were included in the SIP INVITE request or a SIP 
UPDATE request from the originating UE into the outgoing SIP INVITE request; 

4) include in the Accept-Contact header field the feature tag(s) with the value(s) "+g.3gpp.cs-voice" or 
"+g.3gpp.cs-video" or both, marked as explicit; and 

5) send the SIP INVITE request towards the S-CSCF for further routeing. 

When the CSI AS receives a SIP response from the CUA, the CSI AS shall act in accordance with subclause 9.3.3.5. 
When the CSI AS initiates a session towards the originating UE the CSI AS shall: 

1) operate as an application server performing 3"* party call control acting as an initiating B2BUA, specified in 
subclause 5.7.5 of 3GPP TS 24.229 [5] for this request and all future requests in the same dialog; 

2) set the Request-URI and the To header field in the outgoing SIP INVITE request to the SIP URI as indicated in 
the P-Asserted-Identity header field received from the originating UE; 

3) populate the SDP with the media components which were included in the SDP of a SIP re-INVITE request or a 
UPDATE request and not possible to use on the existing session to the originating UE in the outgoing SIP 
INVITE request; and 

4) send the SIP INVITE request towards the S-CSCF for further routeing. 

When the CSI AS receives a SIP response from the originating UE the CSI AS shall handle the response by following 
the rules of the 3GPP TS 24.229 [5]. 

9.3.3.3.4 Subsequent requests 

When the CSI AS receives a subsequent SIP request from the originating UE before it has provided the final SIP 
response to the originating UE (i.e. in early dialog), the CSI AS shall act as follows: 

1) The SIP request which is triggered by the subsequent SIP request from the originating UE shall include 
exactly the same media components as the SIP requests triggered by the initial SIP INVITE request; and 

2) the CSI AS shall not send a SIP request to the already established call leg if the CSI AS has received the final 
SIP response for that call leg. Instead the CSI AS shall include the media description indicating the media on 
the established call leg is ready when responding back to the originating UE. 

Upon receipt of the SIP re-INVITE request or the SIP UPDATE request from the originating UE after the session is 
established, the CSI AS shall follow subclause 9.3.3.4. Handling of other subsequent SIP requests is out of scope of this 
version of the document. 

9.3.3.4 Session Modification 

9.3.3.4.1 Adding an IM Session to an existing CS call 

When the CSI AS receives a SIP re-INVITE request or a SIP UPDATE request from the originating UE and the 
received SDP includes other "m=" lines than "m=audio" line that have non-zero port numbers and there do not exist any 
non voice media session to the CUA, the CSI AS shall initiate a SIP INVITE request requesting the same non-voice 
media as received in the incoming re-INVITE request request or UPDATE request towards the CUA via the IM CN 
subsystem as specified in the subclause 9.3.3.3.3. If there exist a session the CSI-AS shall send an SIP re-INVITE or 
SIP UPDATE request to the CUA in accordance with subclause 9.3.3.4.3. 

When the CSI AS receives the SIP response message from the CUA, it shall be processed according to subclause 
9.3.3.5. 
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When the CSI AS receives a SIP re-INVITE request or a SIP UPDATE request from the CUA and the CSI AS is 
required to setup a new session the set up is performed in accordance with subclause 9.3.3.3.3. Otherwise the CSI-AS 
shall send a SIP re-INVITE request or a SIP UPDATE request to the originating UE including: 

the Request-URI set to the URI received from the originating UE in the Contact header; and 

a new SDP offer, including the media characteristics as received in the incoming SIP re-INVITE or UPDATE 
request, by following the rules of the 3GPP TS 24.229 [5]. 

NOTE: Whether the CSI AS uses the existing dialog to the originating UE or uses a new dialog can depend on 
local policy and received signalling information in the SDP from the originating UE. 

When the CSI AS receives a SIP response message from the originating UE, the responses shall be processed according 
to the rules specified in 3GPP TS 24.229 [5]. 

9.3.3.4.2 Adding a CS call to an existing IMS Session 

When the CSI AS receives a SIP re-INVITE request or a SIP UPDATE request and the received SDP includes an 
additional "m=audio" line which has non-zero port; 

the CSI AS shall check if there is an ongoing voice call between the CUA and the CSI AS which is associated 
with the same session in which the SIP re-INVITE request or a SIP UPDATE request is received; 

a) If a voice call between the CUA and the CSI AS via CS domain does not exist, the CSI AS shall initiate a SIP 
INVITE requesting the same voice media towards the CUA as specified in the subclause 9.3.3.3.2 ; 

b) Otherwise, the CSI AS shall reply with 4xx response. 
NOTE: The multicall setup is not supported within this specification. 

When the CSI AS receives the SIP response from the MGCP, it shall be processed according to the subcaluse 9.3.3.5. 

When the CSI AS receives a SIP re-INVITE request or a SIP UPDATE request and the received SDP includes an 
additional entry in the existing "m=audio" line which has non-zero port; 

the CSI AS shall check if there is an ongoing voice call between the CUA and the CSI AS which is associated 
with the same session in which the SIP re-INVITE or a SIP UPDATE request is received; 

a) If a voice call between the CUA and the CSI AS via CS domain does not exist, the CSI AS shall initiate a SIP 

INVITE requesting the same voice media towards the CUA as specified in the subclause 9.3.3.3.2; 

b) Otherwise the CSI AS shall send an SIP re-INVITE or a SIP UPDATE request to the CUA including: 

the Request-URI set to the URI received from the MGCP in the Contact header; and 

a new SDP offer, including the media characteristics as received in the SIP re-INVITE or a SIP UPDATE 
request , by following the rules of the 3GPP TS24.229 [5]. 

9.3.3.4.3 Modifying an existing CS call and an existing IMS Session 

When the CSI AS receives a SIP re-INVITE request or a SIP UPDATE request where the dialog identifier included in 
the request matches with a dialog identifier of an ongoing session then; 

1) if the SDP media description for voice in the received SIP re-INVITE request or a SIP UPDATE request is 
updated; 

a) the CSI AS shall send a SIP re-INVITE request or a SIP UPDATE request to the MGCP including; 

the Request-URI and the To header field set to the URI received from the MGCP in the Contact header 
field; and 

a new SDP offer, including the media characteristics as received in the SIP re-INVITE or A SIP 
UPDATE request , by following the rules of 3GPP TS 24.229 [5]. 

b) When the CSI AS receives the SIP response from the MGCP, the SIP response shall be processed according 
to subclause 9.3.3.5. 
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2) if the SDP media description for non-voice in the received SIP re-INVITE request or SIP UPDATE request is 
updated; 

a) the CSI AS shall send a SIP re-INVITE request or SIP UPDATE request to the CUA including; 

the Request-URI and the To heder field set to the URI received from the CUA in the Contact header field; 
and 

a new SDP offer, including the media characteristics as received in the SIP INVITE request or a SIP 
UPDATE request, by following the rules of the 3GPP TS 24.229 [5]. 

b) When the CSI AS receives the SIP response from the CUA, the SIP response shall be processed according to 
subclause 9.3.3.5. 

3) if the SDP media description in the received SIP re-INVITE request includes one or more "m=" lines with the 
port number set to zero, the CSI AS shall act as specified in the subclause 9.3.3.6. 

9.3.3.5 Session Combining 

The CSI AS having established one call leg to the CUA and another call leg to the MGCF shall combine the SIP 
responses from the CUA and the MGCF as follows: 

The CSI AS shall act as a B2BUA as per subclause 5.7.5 of 3GPP TS 24.229 [5] with the following additions. 

If the CSI AS receives a SDP answer from both of the two call legs, the CSI AS shall include a SDP answer in a SIP 
response which includes the SDP from both legs in accodance with 3GPP TS 24.229 [5], i.e. the CSI AS shall respond 
to the SIP INVITE request from the originating UE when all SDP media descriptions from both of the two split call legs 
are known to the CSI AS. The SIP response code that is sent to the originating UE by the CSI AS depends on the SIP 
response received from the two call legs and is specified in table 9.3.3.5A. 

If the CSI AS receives only SDP answer from one of the legs, the CSI AS shall include the SDP answer in a SIP 
response in accordance with 3GPP TS 24.229[5]. The SIP response code that is sent to the origninating UE by the CSI 
AS depends on the SIP response received from the two call legs and is specified in table 9.3.3.5A. 

If the CSI AS receives SIP responses without any SDP, the SIP response code that is sent to the originating UE by the 
CSI AS depends on the SIP response received from the two call legs and is specified in table 9.3.3.5A. 

In addition to table 9.3.3.5A, when the CSI AS receives only one SDP answer from one leg while having a SIP 3xx - 
6xx error response(s) from the other leg, the CSI AS shall: 

1) if the SIP error response is received from the MGCF, provide the SIP response to the originating UE as shown in 
table 9.3.3.5A but with the port of the voice media set to in the SDP answer provided to the originating UE; or 

2) if the SIP error response is received from the CUA, provide the SIP response to the originating UE as shown in 
table 9.3.3.5A but with the port of the non-voice media set to in the SDP answer provided to the originating 
UE. 

When the CSI AS receives the SIP responses for the SIP INVITE requests that were sent to the CUA and the MGCF, 
the CSI AS shall: 

1) provide the SIP response to the originating UE as per subclause 5.7.5 of 3GPP TS 24.229 [5]. In this SIP 
response except the final SIP response, the CSI AS shall provide all SDP media description that is received from 
the CUA and the MGCF in the SDP answer; 

2) provide the combined final SIP response to the originating UE only if the final SIP responses arriving from each 
of the two call legs, have the same SIP status code; or 

3) provide the SIP response as shown in the table 9.3.3.5A below to the originating UE if the SIP responses arrived 
from the two call legs have different status codes; 

4) provide a combined SIP 180 (Ringing) response to the originating UE only if the SIP 180 (Ringing) responses 
arrive from each early dialog of the two call legs. When the precondition mechanism is used, the CSI AS shall 
not provide a combined SIP 180 (Ringing) response until the required resource reservations are met for each of 
the two call legs; 
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5) provide - when precondition mechanism is used - a combined SIP 200 (OK) response to the SIP UPDATE 
request to the originating UE only if both SIP 200 (OK) responses to the SIP UPDATE requests which had been 
sent in each of the two call legs arrive; 

6) provide a SIP response to the originating UE including "lOOrel" in the Require header field if at least one of SIP 
responses from either call legs include "lOOrel" in the Required header; and 

7) if due to forking more than one SIP response is received for the non-voice media, choose one which comes from 
the CUA and initiate SIP CANCEL request(s) to cancel the other forked dialog(s). 

NOTE: The CSI AS recognizes the SIP response from the CUA by regarding the media feature tag or by comparing 
contact address in the Contact header with the terminal information stored in the CSI AS. 

If one of two call legs is established earlier than the other, the CSI AS upon receiving a SIP response from the early 
dialog of the other call leg shall include the media description showing the media on the established call leg is ready 
when responding back to the originating UE. 

If the CSI AS does not receive any response from one of call legs towards the CUA within an implementation 
dependent time, the CSI AS shall reject the media of that corresponding leg that has timeout, by indicating such 
rejection within the SDP body media descriptions when the CSI AS response to the originating UE. For the call leg that 
has not responded by timeout, the CSI AS may initiate the SIP CANCEL request to cancel the pending session of the 
corresponding call leg. Any responses received after this timeout are ignored by the CSI AS. 

Table 9.3.3.5A: SIP response (CSI AS to the originating UE) 



Response from MGCF 


Response from CUA 


Response provided by CSI AS to 
the originating UE 


180 


200 


180(When preconditions between the 
UE and CSI AS are met) 


200 


180 


183 


200 


183 


200 


183 


4xx/5xx/6xx 


180 


180(When preconditions between tlie 
UE and CSI AS are met) 


180 


4xx/5xx/6xx 


4xx/5xx/6xx 


183/200 


183/200 


183/200 


4xx/5xx/6xx 


181 


Any response 


Response will be based on local 
policy, i.e. keep the successfully 
established CS call or/and IMS 
session with the calling party. 


Any response 


181 


4xx/5xx/6xx 


4xx/5xx/6xx 


4xx/5xx/6xx (according to the best 
response procedures as specified in 
IETF RFC 3261 [17]) 


603 


Any response 


Either when responding back to the 
originating UE provide an SDP 
answer rejecting the media 
component which is subject to Call 
Barring and thereby allow the 
originating UE to renegotiate, or 
respond to the calling UE with the 
response indicating that call is barred 
and initiate a SIP CANCEL request to 
cancel the other call leg being 
established toward the CUA. 


Any response 


603 


Either when responding back to the 
originating UE provide an SDP 
answer rejecting the media 
component which is subject to Call 
Barring and thereby allow the 
originating UE to renegotiate, or 
respond to the calling UE with the 
response indicating that call is barred 
and initiate a SIP CANCEL request to 
cancel the other call leg being 
established toward the CUA. 
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9.3.3.6 Session Release 

If the CSI AS receives the SIP re-INVITE request or a SIP UPDATE request which includes "m=" lines where the port 
number has been changed to zero from that provided in the previous SDP offer from the originating UE, then: 

1) if the received SDP media description includes the port number set to zero for all "m=audio" lines, the CSI AS 
shall initiate a SIP BYE request to release the session toward the MGCP which is associated with the session 
where the SIP re-INVITE or SIP UPDATE request is received; 

2) if the received SDP media description includes the port number set to zero for a "m=audio" line, the CSI AS 
shall initiate a SIP re-INVITE or a SIP UPDATE request including a SDP with the received "m=audio" lines in 
accordance with3GPP TS 24.229 [5]; 

3) if the received SDP media description includes the port number set to zero for non-"m=audio"lines, the CSI AS 
initiates a SIP re-INVITE request including SDP media description for non-voice toward the CUA; or 

4) if the received SDP media description includes the port numbers set to zero for all the "m=" lines other than 
"m=audio" the CSI AS initiates a SIP BYE request towards the CUA in the IM CN subsystem. 

If the CSI AS receives the SIP BYE request from the originating UE, then; 

1) the CSI AS shall initiate the SIP BYE request to release the session towards the CUA which is associated to the 
session where the SIP BYE request is received and, 

2) the CSI AS shall initiate the SIP BYE request to release the session towards the MGCF which is associated to 
the session where the SIP BYE request is received. 

If the CSI AS recevices the SIP BYE request from the CUA or the MGCF, then; 

1) if there is no remaining session other than the session the SIP BYE request belongs to, the CSI AS initiates a SIP 
BYE request toward the originating UE or, 

2) otherwise, the CSI AS initiates a SIP re-INVITE request to remove corresponding media towards the originating 
UE. 

9.3.3.7 Unregistered Service 

To allow for the provision of unregistered service, the CSI AS may keep the UE capability information after the user 
has been deregistered from the IM CN subsystem. The duration of validity of UE capability information after a UE has 
deregistered from the IM CN subsystem is an operator policy. 

When the CSI AS receives a SIP INVITE request destined for a user who is unregistered to the IM CN subsystem, the 
CSI AS shall follow 9.3.3.3 with the following addition. 

The CSI AS shall not initiate a session toward the IM CN subsystem and shall in the SDP answer provided to the 
originating UE, set the port to for all media except the voice media. 

NOTE 1 : In the case that the CSI terminating service is part of a series of unregistered services for the user, care is 
taken that the trigerring of the CSI AS does not negatively affect the provisioning of other unregistered 
services for that user in the terminating network, ie. the terminating user's service profile iFC is so set up 
to ensure orderly triggering of the CSI AS and the other unregistered services for that terminating user. 

NOTE 2: Fowarding an incoming call to the CUA via CS domain by using Call Forwarding Supplementary Service 
is not in the scope of this document. 

9.3.3.8 Capability exchange with the CSI UE 

When the CSI AS has determined that the network supports the functionality required for CSI sessions between UEs in 
IMS only mode and a CSI capable UE (CUA) and has received an initial INVITE request, then the CSI AS shall 
perform CSI capability exchange with the terminating CSI UE on behalf of the originating IMS UE. The SIP INVITE 
request generated by the CSI AS shall include the User-to-User header as defined in draft-johnston-sipping-cc-uui [18]. 
This User-to-User header shall contain the following CSI capability information in the User-user information element as 
defined in 3GPP TS 24.008 [4] Annex O: 
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1) The IM Status is configured as IM subsystem registered; 

2) The radio environment is configured as capable of simultaneous services; 
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Annex A (normative): 

Media feature tags defined within the current document 

A.1 General 

This subclause describes the media feature tag definitions that are applicable for the 3GPP IM CN Subsystem for the 
realisation of CSI. 

A.2 Definition of media feature tag g.3gpp.cs-voice 

Media feature-tag name: g.3gpp.cs-voice 

ASN.l Identifier: 1.3.6.1.8.2.1 

Summary of the media feature indicated by this tag: This feature-tag indicates that the device supports circuit switched 
voice when combining circuit switched calls and IM sessions. 

Values appropriate for use with this feature-tag: Boolean. 

The feature-tag is intended primarily for use in the following applications, protocols, services, or negotiation 
mechanisms: This feature-tag is most useful in a communications application, for describing the capabilities of a device, 
such as a phone or PDA. 

Examples of typical use: Indicating that a mobile phone can support voice in a circuit switched environment within the 
context of combining a circuit switched voice call with an IM session. 

Related standards or documents: 3GPP TS 24.279: "Combining Circuit Switched (CS) and IP Multimedia Subsystem 
(IMS) services, stage 3" 

Security Considerations: Security considerations for this media feature-tag are discussed in subclause 11.1 of 
RFC 3840 [6]. 

A.3 Definition of media feature tag g.3gpp.cs-video 

Media feature-tag name: g.3gpp.cs-video 

ASN.l Identifier: 1.3.6.1.8.2.2 

Summary of the media feature indicated by this tag: This feature-tag indicates that the device supports circuit switched 
video when combining circuit switched video calls and IM sessions. 

Values appropriate for use with this feature-tag: Boolean. 

The feature-tag is intended primarily for use in the following applications, protocols, services, or negotiation 
mechanisms: This feature-tag is most useful in a communications application, for describing the capabilities of a device, 
such as a phone or PDA. 

Examples of typical use: Indicating that a mobile phone can support video in a circuit switched environment within the 
context of combining a circuit switched video call with an IM session. 

Related standards or documents: 3GPP TS 24.279: "Combining Circuit Switched (CS) and IP Multimedia Subsystem 
(IMS) services, stage 3" 

Security Considerations: Security considerations for this media feature-tag are discussed in subclause 11.1 of 
RFC 3840 [6]. 
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Annex B (informative): 

Example signalling flows for the combining of CS calls with 

IM sessions 

B.1 Scope of signalling flows 

This annex gives examples of signalling flows for the combination of CS calls with IM sessions within the IP 
Multimedia (IM) Core Network (CN) subsystem based on the Session Initiation Protocol (SIP). 

These detailed signalling flows expand on the overview information flows provided in 3GPP TS 23.279 [3]. 



B.2 Introduction 
B.2.1 General 

The signalling flows provided in this annex follow the methodology developed in 3GPP TS 24.228 [11]. The following 
additional considerations apply: 

a) 3GPP TS 24.228 [11] shows separate signalling flows with no configuration hiding between networks, and with 
configuration hiding between networks. There is no combining of CS calls with IM sessions functionality 
associated with this hiding, and therefore such separate signalling flows are not show in the present document; 

b) 3GPP TS 24.228 [11] breaks down the functionality of the various CSCFs. Such intervening activity in the 
CSCFs is in general not relevant to showing the functionality combining of CS calls with IM sessions, and 
therefore the CSCFs are collapsed into a single entity labelled "Intermediate IM CN subsystem entities". 

B.2. 2 Key required to interpret signalling flows 

The key to interpret signalling flows specified in 3GPP TS 24.228 [11] subclause 4.1 applies with the additions 
specified below: 

- tel:+12125551 1 1 1 is the tel URI, PMI-0007 is the personal ME identifier and UCV-04 is the UE capability 
version relating to CUA#1; 

- tel:+12125552222 is the tel URI, PMI-0EA2 is the personal ME identifier and UCV-OD is the UE capability 
version relating to CUA#2; 

- tel:+12125553333 is the tel URI of the UE#1 and 

- sip:user3_pubhcl @homel .net is the SIP URI of the UE#1 . 



Each signalling flow table contains descriptions for headers where the content of the header is new to that signalling 
flow, as is already performed in 3GPP TS 24.228 [11]. 

However, 3GPP TS 24.228 [11] includes extensive descriptions for the contents of various headers following each of 
the tables representing the contents of the signalling flows. Where the operation of the header is identical to that shown 
in 3GPP TS 24.228 [11], then such text is not reproduced in the present document. 

Additional text can also be found on the contents of headers within 3GPP TS 24.228 [11] in addition to the material 
shown in the present document. 

In order to differentiate between messages for SIP and media, the following notation is used: 
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INVITE 



SETUP 



-► SIP message 

-► CS message 

►- Media over a PS connection 



Media over a CS connection 



Figure B.2.2-1 : Signalling flow notation 



B.3 Signalling flows demonstrating CSI session setup 
when no CS call has yet been set up 

B.3.1 Introduction 

This subclause provides signalling flows for CSI session setup, using session-based messaging as an example, 
established before any CS call has been established. 

The signalling flows are based on the session establishment flows in subclause A. 3 of 3GPP TS 24.247 [10], with some 
additions related to CSI. The UAC includes the media feature tags g.3gpp.cs-voice and g.3gpp.cs-video in the Accept- 
Contact header. 

B.3. 2 Establishing a CSI session when no CS call has yet been 
set up 

Figure B.3. 2-1 shows the establishment of an MSRP session between two users as well. A CS call is then established 
after MSRP messages are communicated over the established PS connection. 
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CUA#1 



Intermediate IM CN subsystem 
entities 



Intermediate CS entities 



CUA#2 



1 . OPTIONS request and response 



-2. INVITE- 



-3. 100 Trying - 



4a. User-Agent P-CSCF#1 -> P-CSCF#2 
4b. INVITE request S-CSCF -> l-CSCF 



-5. INVITE- 



-6. 100. Trying - 



7, Reserve IP-CAN 
bearer for media 



8. Reiiabie exclnange of 9DP 



-10. 200OK- 



-11. ACK- 



12. Reserve IP-CAN 
bearer for media 



-9. 200OK- 



-13. ACK- 



1 4. Estabiishment of the MSRP session 



16. SETUP 



17. CALL PROCEEDING 



■ 15. Media exchange in PS domain 



18. SETUP 



19. CALL CONFIRM 



20. Early Assignment of User Plane Resources 



21. ALERTING 



22. Early Assignment of User Plane Resources 



23. ALERTING 



26. CONNECT 



27. CONNECT ACKNOWLEDGE 



28. Active Call in CS domain 



24. CONNECT 



25. CONNECT 
ACKNOWLEDGE 



Figure B.3.2-1 : Establishment of a session before a CS call is established 

The details of the signalhng flows are as follows: 
1 . UE capabilities exchange 
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Both UEs have performed a capability exchange. In the here shown example both UEs transfer their UE 
capability version and personal ME identifier as a part of the capability exchange. An example for capability 
exchange without the usage of UE capability version and personal ME identifier can be found in subclause 
B.6. 

2. INVITE request (CUA#1 to P-CSCF#1) - see example in table B.3.2-2 

The originating CUA wants to initiate a session with the terminating CUA. In this example, the originating 
CUA creates a local MSRP URL, which can be used for the communication between the two user agents. It 
builds a SDP Offer containing the generated MSRP URL and assigns a local port number for the MSRP 
communication. 

The originating CUA declares its capabilities for CS-voice and CS-video, and requests to reach a UE with cs- 
voice or cs-video capabilities. The originating CUA includes its personal ME identifier and UE capability 
version in the User- Agent header. 

Table B.3.2-2: INVITE request (CUA#1 to P-CSCF#1) 



INVITE tel:+12125552222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max- Forwards : 70 

Route: <sip :pcscf 1 . visitedl .net : 75 31; lr;comp=sigcomp>, <sip lorigOscscf 1 .homel .net; lr> 

P- Preferred- Identity: <tel : +12 12 5551111 > 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=171828 

To: <tel:+12125552222> 

Call -ID: Cb0 3a0s0 9a2sdfglkj4 90333 

Cseq: 127 INVITE 

Require: sec-agree 

Proxy-Require: sec-agree 

Supported: gruu 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=987S5432 ; spi-s=87S54321; 

port-c=B642; port-s=7531 
Contact : <sip : userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lldO-a765-OOaOc91e6bf 6 

; comp=sigcomp>; +g. 3gpp. cs- voice; +g. 3gpp. cs-video 
Accept - Contact : * , +g. 3gpp . cs-voice, +g. 3gpp . cs-video;explicit 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, OPTIONS 
User-Agent: PMI-0007, UCV-04 

Accept : application/sdp, application/3gpp-ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933S15 IN IPS 5555 :: aaa :bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=message 34 02 TCP/MSRP * 

a=accept-types :message/cpim text/plain text/html image/jpeg image/gif video/3gpp 

a=path:msrp: // [5555 : : aaa: bbb: ccc :ddd] : 34 02/slll2 71; tcp 

a=max-size : 131072 



SDP The SDP contains a set of content types supported by CUA#1 and desired by the user at CUA#1 

for this session in the accept-types attribute and indicates the maximum size message that can be 
received by CUA#1 in the max-size attribute. 

3. 100 (Trying) response (P-CSCF#1 to CUA#1) 

The P-CSCF responds to the INVITE request with a 100 (Trying) provisional response as described in 
subclause A. 3 of 3GPP TS 24.247 [10]. 

4a. User-Agent (P-CSCF#1 to P-CSCF#2) 

The User- Agent header field is transparently passed from P-CSCF#1 to P-CSCF#2. 
4b. INVITE request (S-CSCF#1 to I-CSCF#2) - see example in table B.3.2-4b 

S-CSCF#1 forwards the INVITE request to the I-CSCF#2, after mapping the tel URI to a SIP-URL 
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Table B.3.2-4b: INVITE request (S-CSCF#1 to l-CSCF#2) 



INVITE sip:user2_publicl@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1 , SIP/2. 0/UDP 

pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 

[5555 : : aaa :bbb : ccc :ddd] : 13 57;comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 68 

Record- Route : <sip:scscfl .homel .net ; lr>, <sip : pcscf 1 .visitedl .net ; lr> 
P-Asserted- Identity : 

P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Supported: 
Contact : 
Accept-Contact : 
Allow: 
Accept : 
User Agent : 
Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 

t= 

m= 
a= 



5. INVITE request (P-CSCF#2 to CUA#2) - see example in table B.3.2-5 

P-CSCF#2 forwards the INVITE request to the terminating CUA. 
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Table B.3.2-5: INVITE request (P-CSCF#2 to CUA#2) 



INVITE sip: [5555 : :eee : fff :aaa:bbb] : 8805;comp=sigcomp SIP/2.0 

Via: SIP/2. 0/UDP pcscf2 .visited2 .net :5088;comp=sigcomp;branch=z9hG4bK361k21.1, SIP/2. 0/UDP 

scscf2.home2 .net ;branch=z9hG4bK764z87 . 1, SIP/2 .0/UDP 

icscf2_s.home2 .net ;branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 

pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 

[5555 : : aaa :bbb: ccc :ddd] : 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 
Max-Forwards: 65 
Record- Route : <sip :pcscf 2 . visited2 .net : 5 088 ; lr;comp=sigcomp>, <sip:scscf2 .home2 .net ; lr>, 

<sip:scscfl .homel .net ; lr>, <sip : pcscf 1 .visitedl .net; lr> 
P-Asserted- Identity : 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 
Supported 
Contact : 
Accept-Contact : 
Allow: 
Accept : 
User-Agent : 
P-Called-Party-ID: 
Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 
t= 

m= 
a= 
a= 

a= 



6. 100 (Trying) response (CUA#2 to P-CSCF#2) 

The terminating CUA sends a 100 (Trying) provisional response to P-CSCF#2 as described in subclause A. 3 
of3GPPTS 24.247 [10]. 

7. Reserve IP-CAN bearer for media 

The terminating CUA accepts the message session. The terminating CUA reserves an IP-CAN bearer for the 
message session media component. 

8. Reliable exchange of SDP 

SDP is conveyed between CUA#1 and CUA#2. The mechanism for this is not relevant for the example and is 
not described. 

9. 200 (OK) response (CUA#2 to P-CSCF#2) - see example in table B.3.2-9 

After reserving an IP-CAN bearer for the message session media component the terminating CUA sends a 
200 (OK) response for the INVITE request containing SDP that indicates that the terminating CUA has 
accepted the message session and listens on the MSRP TCP port returned in the path attribute in the answer 
for a TCP SETUP from the originating CUA. 

CUA#2 declares support only for CS-voice, not CS-video in its Contact header. The terminating CUA 
includes its personal ME identifier and UE capability version in the Server header. 
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Table B.3.2-9: 200 (OK) response (CUA#2 to P-CSCF#2) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net : 5088 ; comp=sigcomp;branch=z9hG4bK361k21 . 1 , SIP/2. 0/UDP 
scscf2 .home2 .net ;branch=z9hG4bK764z87 . 1, SIP/2 .0/UDP 
icscf2_s.home2 .net ;branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 
pcscfl.visitedl.net;branch=z9hG4bK24 0f34 .1, SIP/2 .0/UDP 
[5555 : :aaa:bbb:ccc:ddd] : 1357;comp=sigcomp;branch=z9hG4bKnashds7 

Record- Route : <sip : pcscf 2 . visited2 .net : 5088 ; lr;comp=sigcomp>>, <sip:scscf2 .home2 .net ; lr>, 
<sip:scscfl .homel .net ; lr>, <sip : pcscf 1 . visitedl .net ; lr> 

Privacy: none 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

From: <sip :userl_publicl@homel .net>; tag=171828 

To: <tel:+1212 5 5 52222>;tag=31415 9 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Supported: gruu 

Contact : <sip: user2_publicl@home2 .net ;gr=urn:uuid: 2ad8950e-48a5-4a74-8d99- 
ad76cc7f c74 ; comp=sigcomp> ; +g . 3gpp . cs-voice 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, OPTIONS 

Server: PiyiI-0EA2, UCV-OD 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933617 IN IP6 5555:: eee : f f f : aaa : bbb 

s = - 

c = IN IP6 5555 : :eee:fff :aaa:bbb 

t = 

m=message 3402 TCP/MSRP * 

a=accept-types : text/plain text/html message/cpim 

a=path:msrp:// [5555: : eee : f f f : aaa : bbb] : 34 02/s2 3416 7; tcp 

a=max-size : 6 5536 



SDP The SDP contains the set of offered content types supported by CU A#2 and desired by the user at 

CUA#2 for this session in the accept-types attribute and indicates the maximum size message that 
can be received by CUA#2 in the max-size attribute. 



10. 200 (OK) response (P-CSCF#1 to CUA#1) - see example in table B.3.2-10 

P-CSCF#1 forwards the 200 (OK) response to the originating CUA. 
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Table B.3.2-10: 200 (OK) response (P-CSCF#1 to CUA#1) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc :ddd] : 1357 ; comp = sigcomp;branch=z9hG4bKnashds7 

Record- Route : <sip ipcscf 2 . visited2 .net; lr>, <sip:scscf2 .home2 .net; lr>, 

<sip:scscfl .homel .net; lr>, <sip:pcscfl . visitedl .net : 7531; lr;comp=sigcomp> 
P-Asserted- Identity : 
Privacy: 
From: 
To: 

Call-ID: 
CSeq: 

Supported: 
Contact : 
Allow: 
Server: 
Content-Type : 
Content-Length : 

v= 
o= 
s= 
c= 
t= 

m= 
a= 
a= 
a= 



P-Asserted-Identity: This header field is added by the intermediate IM CN subsystem entities in accordance with 

3GPPTS 24.229 [5]. 

1 1. ACK request (CUA#1 to P-CSCF#1) - see example in table B.3.2-11 

The CUA responds to the 200 (OK) response with an ACK request sent to the P-CSCF#1. 

Table B.3.2-11: ACK request (CUA#1 to P-CSCF#1) 



ACK sip: user2_publicl@home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d99-ad76cc7f c74 

;comp=sigcomp SIP/2.0 
Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 7 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
Route : <sip :pcscf 1 .visitedl .net : 7531; Ir ; comp=sigcomp> , <sip:scscfl .homel .net; lr>, 

<sip:scscf2 .home2 .net; lr>, <sip :pcscf 2 . visited2 .net ; lr> 
From: <sip :userl_publicl@homel .net>; tag=17182 8 
To : <sip : user2_publicl@home2 . net> ; tag=314159 
Call-ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 127 ACK 
Content-Length: 



12. Reserve IP-CAN bearer for media 

The originating CUA reserves an IP -CAN bearer for the message session media component. 

13. ACK request (P-CSCF#2 to CUA#2) - see example in table B.3.2-13. 

P-CSCF#2 forwards the ACK request to the terminating CUA. 
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Table B.3.2-13: ACK request (P-CSCF#2 to CUA#2) 



ACK sip: [5555 : :eee : fff :aaa:bbb] : 8805;comp=sigcomp SIP/2.0 




Via: SIP/2 . 0/UDP pcscf2 .visited2 .net : 5 088 ;comp=sigcomp;branch=z9hG4bK361k21 . 1, 


SIP/2. 0/UDP 


scscf2.home2.net;branch=z9hG4bK764z87.1, SIP/2. 0/UDP 




scscfl.homel.net;branch=z9hG4bK332b23.1, SIP/2. 0/UDP 




pcscf 1 . visitedl .net ;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 




[5555 : : aaa :bbb : ccc :ddd] : 13 57;comp=sigcomp;branch=z9hG4bKnashds7 




Max- Forwards : 6 6 




From: 




To: 




Call-ID: 




Cseq: 




Content-Length: 





14. Establishment of the MSRP session 

The CUAs will establish the MSRP session as described in subclause A.3 of 3GPP TS 24.247 [10]. 

15. Media exchange in PS domain 

The CUAs will transfer media over the PS domain. 

16. Initiation of CS call estabUshment with SETUP from originating side (from CUA#1 to MSC#1) 

CUA#1 starts the CS call towards CUA#2 sending out the SETUP. 
Specifically for CSI, the SETUP message includes:- 

Called Party Number = [(Numbering plan identifier = ISDN/telephony numbering plan), 

(type of number = international number), (Number digits = 12125552222)] 
User-User IE = [(Protocol ID =3GPP capability exchange protocol), (Radio Environment =1), 

(IM Status = IM subsystem registered), (Personal ME Identifier = 0007), (UE capability version = 
04)]. 

CUA#1 ensures that the Personal ME Identifier within the User-User IE of the SETUP correlates to the 
Personal ME Identifier used by CUA#1 in the preceding IM session. 

17. CALL PROCEEDING (MSC#1 to CUA#1) 

MSC#1 after call processing checks replies to CUA#1 with Call Proceeding. 
MSC#1 progresses the CS Call by contacting MSC#2. Intermediate CS entities could be involved. 
The User-User information provided by CUA#1 is forwarded by MSC#1 towards MSC#2. 
There is no specific CSI information in CALL_PROCEEDING. 

18. Initiation of CS terminating call with SETUP towards called party (from MSC#2 to CUA#2) 

MSC#2 starts the terminating call by initiating SETUP to CUA#2. 

Specifically for CSI, the SETUP message includes :- 

Called Party Number = [(type of number = international number ), 

(Numbering plan identifier = ISDN/telephony numbering plan), (Number digits = 12125552222)] 

Calling Party Number = [(presentation indicator = Presentation allowed), 

(screening indicator = Network provided), (type of number = international number ), 
(Numbering plan identifier = ISDN/telephony numbering plan), (Number digits = 12125551 1 1 1)] 
User-User IE = [(Protocol ID =3GPP capability exchange protocol), (Radio Environment =1), 

(IM Status = IM subsystem registered), (Personal ME Identifier = 0007), (UE capability version = 
04)]. 

The Personal ME Identifier provided by CUA#1 is used by CUA#2 to relate to the appropriate remote 
terminal having the parallel IM session. The UE capability version provided by CUA#1 is used by CUA#2 to 
check whether the terminal capabilities of CUA#1 are already known by CUA#2. 

19. CALL CONFIRM indicating terminating CS Call is being processed (from CUA#2 to MSC#2) 

CUA#2 on accepting the terminating call for further processing respond to MSC#2 with CALL_CONFIRM. 
There is no specific CSI information in CALL_CONFIRM. 
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20. Allocation of user plane resources 

MSC#2 initiate provision of user plane resources. In this example call flow, this allocation takes place at this 
instance in time, but the network can opt to allocate resources after message 24 but certainly completes the 
allocation before message 25. 
There are no CSI specifics. 

21. ALERTING indicating end user is alerted, (from CUA#2 to MSC#2) 

When alerting towards the end user is started (ie. end user ringing) CUA#2 indicates that the call has been 

delivered by sending ALERTING to MSC#2. 

There are no CSI specifics in this message; in particular, User-User Information Element is not provided. 

22. Originating NW allocates user plane resources 

When MSC#2 receives ALERTING (see previous message 21), MSC#2 conveys this through Intermediate 

CS entities to MSC#1. Knowing that the call has delivered to far end user, MSC#1 initiates allocation of user 

plane resources to originating CUA#1. 

MSC#1 could have opt to allocate user plane resources to CUA#1 much earlier in the messaging sequence 

(eg. after CALL_PROCEEDING) or ]VISC#1 could allocate user plane resource much later eg. just before 

sending of message 26. 

This example flow chooses to indicate user plane resources being allocated at this point in time. 

23. ALERTING indicating far end alerting has started (from MSC#1 to CUA#1) 

MSC#1 sends to CUA#1 ALERTING indicating that the far end user is being alerted. This indication 
together with available user plane resource allow for ring tone to be provided to the originating user by the 
network. If the network had opted not to allocate user plane resources, then this ALERTING will allow the 
CUA#1 to generate local indications to the user that the call has been delivered to the far end user. 

24. CONNECT - far end user answers the call (from CUA#2 to MSC#2) 

When the user answers the call, CUA#2 sends CONNECT to MSC#2. 

Specifically for CSI, the CONNECT message includes:- 

User-User IE = [(Protocol ID =3GPP capability exchange protocol), (Radio Environment =1), 

(IM Status = IM subsystem registered), (Personal ME Identifier = 0EA2), (UE capability version = 
OD)]. 

CUA#2 provides its Personal ME Identifier and UE capability version within the User-User IE. This Personal 
ME Identifier and UE capability version is the same as that provided by CUA#2 in 200 OK (message step 9) 
of the IM session. 

CUA#2 sending CONNECT starts connecting to the user plane resources. 

25. CONNECT ACKNOWLEDGE (from MSC#2 to CUA#2) 

Upon getting CONNECT, MSC#2 starts through connecting the call from the far end through the 
intermediate CS entities to MSC#L MSC#2 indicates this by sending CONNECT_ACKNOWLEDGE to 
CUA#2 and thus allowing CUA#2 to progress to active call state. 

MSC#2 conveys call acceptance to MSC#1 forwarding any User-User information to MSC#1 that is included 
in the CONNECT from CUA#2. 

26. CONNECT - far end has answered the call (from MSC#1 to CUA#1) 

MSC#1 indicates far end has answered the terminating call by sending CONNECT to CUA#L MSC#1 
having through connected the call on the network side now awaits CUA#1 to connect to the allocated user 
plane resources. 

Specifically for CSI, the CONNECT message includes: 

Connected Number = [(presentation indicator = Presentation allowed), 

(screening indicator = Network provided), (type of number = international number), 
(Numbering plan identifier = ISDN/telephony numbering plan), (Number digits = 12125552222)] 
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User-User IE = [(Protocol ID =3GPP capability exchange protocol), (Radio Environment =1), 

(IM Status = IM subsystem registered), (Personal ME Identifier = 0EA2), (UE capability version = 
OD)]. 

The Personal ME Identifier provided by CUA#2 is used by CUA#1 to relate to the appropriate remote 
terminal having the parallel IM session. The UE capability version provided by CUA#2 is used by CUA#1 to 
check whether the terminal capabilities of CUA#2 are already known by CUA#1. 

27. CONNECT ACKNOWLEDGE (from CUA#1 to MSC#1) 

CUA#1 receiving CONNECT and with available user plane through connects the call and return 
CONNECT_ACKNOWLEDGE to MSC#1. The CONNECT ACKNOWLEDGE allows the network to 
progress to active call state. There are no CSI specifics in CONNECT ACKNOWLEDGE 

28. CS Call takes place 

The CS call takes place. 



B.4 Signalling flows demonstrating CSI session setup 
when a CS call is already established 

B.4.1 Introduction 

This subclause provides signalling flows for CSI session setup, using video session as an example of the IM session, 
established after any CS call has been established. 

The flows show some additions related to CSI. The CUA includes the media feature tags g.3gpp.cs-voice and 
g.3gpp.cs-video in the Accept-Contact header and in the Contact header. The User Agent and Server Header carries the 
personal ME identifier. 

B.4. 2 Establishing a CSI session when CS call has been setup 

Figure B.4. 2-1 shows the establishment of video session between two users. A CS call is established before the video 
session is established. 

It is assumed that both the originating CUA and terminating CUA are using an IP-CAN with a separate bearer for SIP 
signalling which means that each CUA needs to provide resource reservation before starting the video session. 
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CUA#1 



Intermediate IM CN subsystem 
entities 



Intermediate CS entities 



1. CS Call Setup 



2. OPTDNS request and response 



-3. INVITE- 



5. Reserve IP-CAN 
bearer for media 



-4. 100 Trying - 



6a. User-Agent P-CSCF#1 - P-CSCF#2 
6b. INVITE request S-CSCF -> l-CSCF 



-11. 183 OK- 



13. IP-CAN 

bearer for media 

Is available 



-15. UPDATE- 



-18. 200 OK- 



-20. 200 OK- 



-21.ACK- 



-7. INVfTE- 



-8. 100. Trying- 



-10. 183 OK- 



12. PRACK -200(OK) exchange 



-16. UPDATE- 



-17. 200 OK- 



-19. 200 OK- 



-22. ACK- 



21. Establishment of the Video session 



CUA#2 



9. Reserve IP-CAN 
bearer for media 



14.IP-CAN bearer for 
media is available 



Figure B.4.2-1 : Establishment of a video session after a CS call is established 
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The details of the signalling flows are as follows: 

1. CScall 

A CS call setup is performed according to subclause B.5. 

2. UE capabilities exchange 

Both UEs have performed a capability exchange. In the here shown example both UEs transfer their UE 
capability version and personal ME identifier as a part of the capability exchange. An example for capability 
exchange without the usage of UE capability version and personal ME identifier can be found in subclause 
B.6. 

3. INVITE request (CUA#1 to P-CSCF#1) - see example in table B.4.2-2 

CUA#1 wants to initiate a session with the terminating CUA. In this example, the CUA#1 creates a video 
session as the IM session. CUA#1 includes the 'precondition" and lOOrel' options tag in the supported 
header. 

CUA#1 indicates, using the SDP Capability Negotiation mechanism, that it supports and is willing to use 
AVPF transport for the video stream and the audio stream. 

CUA#1 indicates that it supports precondition and it indicates that it supports reliable provisional responses. 
However, it does not use the "Require' header for these capabilities. 

CUA#1 does not have available the resources that are necessary to transport the media. 

For this example it is assumed, that signalling encryption was negotiated between CUA#1 and P-CSCF in the 
security mode set-up procedure during the last successful authentication. This option will only be shown in 
this example. 

CUA#1 declares its capabilities for CS-voice and CS-video, and requests to reach a UE with CS-voice or CS- 
video capabilities by including these media feature tags in the Accept-contact header and includes its 
personal ME identifier and UE capability version in User- Agent header. 

Table B.4.2-2: INVITE request (CUA#1 to P-CSCF#1) 



INVITE tel:+12125552222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : <sip :pcscf 1 . visitedl .net : 7531; lr;comp=sigcomp>, <sip : origOscscf 1 .homel .net; lr> 

P- Preferred- Identity: <tel : +12 12 5551111 > 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=171828 

To: <tel:+12125552222> 

Call -ID: Cb0 3a0s0 9a2sdfglkj4 90333 

Cseq: 127 INVITE 

Require: sec-agree 

Supported: precondition, lOOrel, gruu 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-9S ; spi-c=987S5432 ; spi-s=87S54321; 

port-c=8642; port-s=7531 
Contact : <sip : userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lldO-a765-OOaOc91e6bf 6 

; comp=sigcomp> ; +g . 3gpp . cs-voice ; +g . 3gpp . cs-video 
Accept - Contact : *, +g . 3gpp . cs-voice, +g. 3gpp . cs-video;explicit 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, OPTIONS 
Accept : application/sdp, application/3gpp-ims+xml 
User-Agent: PMI-0007, UCV-04 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=video 49232 RTP/AVP 107 

a=tcap : 1 RTP/AVPF 

a=pcfg:l t=l 
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b=AS:64 . 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 

a=rtpmap:107 H263/90000 

a=fmtp 107 profile=0 level=45 



SDP The SDP contains the video codec supported by CUA#1 and desired by the user at CUA#1 for this 

session. The precondition attributes are also included. 

4. 100 (Trying) response (P-CSCF#1 to CUA#1) 

The P-CSCF responds to the INVITE request with a 100 (Trying) provisional response as described in 
subclause A. 3 of 3GPP TS 24.247 [10]. 

5. Reserve IP CAN bearer for media 

CUA#1 starts resource reservation based on the SDP. 
6a. User-Agent (P-CSCF#1 to P-CSCF#2) 

The User- Agent header field is transparently passed from P-CSCF#1 to P-CSCF#2. 

6b. INVITE request (S-CSCF#1 to I-CSCF#2) - see example in table B.4.2-3 

S-CSCF#1 forwards the INVITE request to the I-CSCF#2, after replacing the tel URI with a SIP-URI in the 
Request URI. 

Table B.4.2-3: INVITE request (S-CSCF#1 to l-CSCF#2) 



INVITE sip:user2_publicl®home2 .net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1 , SIP/2 . 0/UDP 
pcscf 1 . visitedl .net ;branch=z9hG4bK24 0f 34 . 1 , SIP/2 . 0/UDP 
[5555 : :aaa:bbb: ccc : ddd] : 13 5 7 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 68 

Route : <sip : pcscf 1 .visitedl .net : 7531; Ir ; comp=sigcomp> , <sip :orig@scscf 1 .homel .net; lr> 

Record- Route : <sip:scscfl .homel .net; lr>, <sip:pcscfl .visitedl .net; lr> 

P-Asserted-Identity : <tel : +12125551111> 

Privacy: 

From: 

To: 

Call-ID: 

Cseq: 

Supported: 

Contact : 

Accept -Contact : 

Allow: 

Accept : 

User-Agent : 

Content-Type : 

Content-Length: 

v= 
o= 
s= 
c= 
t= 

m= 
a= 
a= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



7. INVITE request (P-CSCF#2 to CUA#2) - see example in table B.4.2-4 

P-CSCF#2 forwards the INVITE request to the terminating CUA. 
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Table B.4.2-4: INVITE request (P-CSCF#2 to CUA#2) 



INVITE sip: [5555: :eee:fff: aaa :bbb] : 88 05 ; comp=sigcomp> ; +g. 3gpp . cs -voice 

Via: SIP/2. 0/UDP pcscf2 .visited2 .net :5088;comp=sigcomp;branch=z9hG4bK361k21.1, SIP/2. 0/UDP 

scscf2.home2 .net ;branch=z9hG4bK764z87 . 1, SIP/2 .0/UDP 

icscf2_s.home2 .net ;branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 

pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 

[5555 : : aaa :bbb: ccc :ddd] : 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 
Max-Forwards: 65 
Record- Route : <sip :pcscf 2 . visited2 .net : 5 088 ; lr;comp=sigcomp>, <sip:scscf2 .home2 .net ; lr>, 

<sip:scscfl .homel .net ; lr>, <sip : pcscf 1 .visitedl .net; lr> 
P-Asserted- Identity : 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Supported: 
Contact : 
Accept-Contact : 
Allow: 
Accept : 
User-Agent : 
P-Called-Party-ID: 
Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 
t= 

m= 
a= 
a= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 



8 . 100 (Trying) response (CUA#2 to P-CSCF#2) 

The terminating CUA sends a 100 (Trying) provisional response to P-CSCF#2 as described in subclause A. 3 
of3GPPTS 24.247 [10]. 

9. Reserve IP-CAN bearer for media 

The terminating CUA sets up the bearer in accordance with the received SDP.. 

10. 183 (session progress) response (CUA#2 to P-CSCF#2) - see example in table B.4.2-5 

CUA#2 declares support for "CS-voice" and "CS-video" in its Contact header. The CUA includes the 
personal ME identifier and the UE capability version in the Server header. CUA#2 requires resource 
reservation and supports the precondition mechanism. 
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Table B.4.2-5: 183 (session progress) response (CUA#2 to P-CSCF#2) 



SIP/2.0 183 Session progress 

Via: SIP/2. 0/UDP pcscf 2 . visited2 .net : 5088 ;comp=sigcomp;branch=z9hG4bK361k21 . 1, SIP/2. 0/UDP 

scscf2.home2 .net ;branch=z9hG4bK764z87 . 1, SIP/2 .0/UDP 

icscf2_s.home2 .net ;branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 

pcscfl.visitedl.net;branch=z9hG4bK24 0f34 .1, SIP/2 .0/UDP 

[5555 : :aaa:bbb:ccc:ddd] : 1357;comp=sigcomp;branch=z9hG4bKnashds7 
Record- Route : <sip : pcscf 2 . visited2 .net : 5088 ; lr;comp=sigcomp>>, <sip:scscf2 .home2 .net ; lr>, 

<sip:scscfl .homel .net ; lr>, <sip : pcscf 1 . visitedl .net ; lr> 
Privacy: none 

From: <sip :userl_publicl®homel .net>; tag=171828 
To: <tel:+1212 5552222>;tag=31415 9 
Call -ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 127 INVITE 

Contact : <sip: user2_publicl@home2 .net ;gr=urn:uuid: 2ad8950e-48a5-4a74-8d99- 
ad76cc7f c74 ;comp=sigcomp>; +g. 3gpp . cs -voice, +g. 3gpp . cs -video 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, OPTIONS 
Require: lOOrel, precondition 
Supported: gruu 
Server: PMI-0EA2, UCV-OD 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933617 IN IP6 5555:: eee : f f f : aaa : bbb 

s = - 

c = IN IP6 5555 : :eee:fff :aaa:bbb 

t = 

m=video 49234 RTP/AVPF 107 

a=acfg:l t=l 

b=AS:64 .0 

a=curr:qos remote none 

a=curr:qos local none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=conf:qos remote sendrecv 

a=inactive 

a=rtpmap:107 H263/90000 

a=fmtp 107 profile=0 level=45 



1 1 . 183 (session progress) response (P-CSCF#1 to CUA#1 ) - see example in table B.4.2-6 
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Table B.4.2-6: 183 (session progress) response (P-CSCF#1 to CUA#1 ) 



SIP/2.0 183 Session progress 

Via: [5555: : aaa :bbb : ccc :ddd] : 1357;comp=sigcomp;branch=z9hG4bKnashds7 

Record- Route : <sip :pcscf 2 . visited2 .net : 5088 ; lr;comp=sigcomp>, <sip:scscf2 .home2 .net ; lr>, 

<sip:scscfl .homel .net; lr>, <sip:pcscfl . visitedl .net; lr> 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 
RSeq: 

P-Asserted-Identity: < user2_publicl@home2 .net>, < tel : +12125552222> 
Contact : 
Allow: 
Require : 
Supported: 
Server: 
Content-Type : 
Content-Length : 

v=0 

o=- 

s=- 

c= 

t= 

m= 
a= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



12. PRACK-200 Exchange 

13. IP-CAN bearer available for media 

The IP-CAN bearer at CUA#1 is established. 

14. IP-CAN bearer available for media. 

The IP-CAN bearer at CUA#2 is established. 

15. UPDATE request (CUA#1 to P-CSCF#1 ) - see example in table B.4.2-7 

CUA#1 indicates that it can send and receive media. 
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Table B.4.2-7: UPDATE request (CUA#1 to P-CSCF#1 ) 



UPDATE <sip: user2_publicl@home2 .net ;gr=urn:uuid: 2ad8950e-48a5-4a74-8d99-ad76cc7f c74 

;comp=sigcomp> 
Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max-Forwards: 70 

Route : <sip :pcscf 1 . visitedl .net : 75 31; lr;comp=sigcomp>, <sip :orig@scscf 1 .homel .net; lr> 
From: <sip :userl_publicl@homel .net>; tag=171828 
To: <tel:+12125552222> tag=314159 
Call -ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 12 9 UPDATE 
Require: sec -agree 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321; portl=7531 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=video 49232 RTP/AVPF 107 

b=AS:64.0 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=sendrecv 

a=rtpmap:107 H263/90000 

a=fmtp 107 profile=0 level=45 



16. UPDATE request (P-CSCF#2 to CUA#2 )- see example in table B.4.2-8 

The CUA#2 can start alerting. 

Table B.4.2-8: UPDATE request (P-CSCF#2 to CUA#2) 



UPDATE <sip: user2_publicl@home2 .net ;gr=urn:uuid: 2ad8950e-48a5-4a74-8d99- 
ad76cc7f c74 ;comp=sigcomp> 

Via: : SIP/2. 0/UDP pcscf 2 . visited2 . net : 5088 ; comp=sigcomp;branch=z9hG4bK361k21 . 1 , 
SIP/2 .0/UDP scscf2.home2 .net ;branch=z9hG4bK764z87 . 1, SIP/2 . 0/UDP 
icscf2_s.home2 .net ;branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP 
scscfl. homel. net ;branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 
pcscf 1. visitedl. net ;branch=z9hG4bK24 Of 34 .1, SIP/2 . 0/UDP 
[5555 : : aaa :bbb: ccc :ddd] : 1357;comp=sigcomp;branch=z9hG4bKnashds7 

Max- Forwards : 68 

From: 

To: 

Call-ID: 

Cseq: 

Content-Type : 

Content-Length : 

v= 
o= 
s= 
c= 
t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 



17. 200 (OK) response (CUA#2 to P-CSCF#2) - see example in table B.4.2-9 

CUA 2 indicates that media can be received and sent. 



£75/ 



3GPP TS 24.279 version 1 0.0.0 Release 1 46 ETSI TS 1 24 279 V1 0.0.0 (201 1 -03) 

Table B.4.2-9: 200(OK) response (CUA#2 to P-CSCF#2) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net : 5088 ; comp=sigcomp;branch=z9hG4bK361k21 . 1 , SIP/2. 0/UDP 

scscf2 .home2 .net ;branch=z9hG4bK764z87 . 1, SIP/2 .0/UDP 

icscf2_s.home2 .net ;branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 

pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 

[5555 : : aaa :bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 
From: <sip :userl_publicl@homel .net>; tag=171828 
To: <tel:+1212 5 5 52222>;tag=31415 9 
Call -ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 12 9 UPDATE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933617 IN IP6 5555:: eee : f f f : aaa : bbb 

s = - 

c = IN IP6 5555 : :eee:fff :aaa:bbb 

t = 

m=video 49234 RTP/AVPF 107 

b=AS:64 .0 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=sendrecv 

a=rtpmap:107 H2 63/90000 

a=fmtp 107 profile=0 level=45 



18. 200 (OK) response (P-CSCF#1 to CUA#1) - see example in table B.4.2-10 

Table B.4.2-10: 200(OK) response (P-CSCF#1 to CUA#1) 



SIP/2.0 200 OK 

Via: [5555: : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

Cseq: 

Content-Type : 

Content -Length: 

v=0 
o=- 
s=- 
c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



19. 200 (OK) response (CUA#2 to P-CSCF#2) - see example in table B.4.2-11 

CUA#2 accepts the session. 
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Table B.4.2-11 : 200 (OK) response (CUA#2 to P-CSCF#2) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net : 5088 ; comp=sigcomp;branch=z9hG4bK361k21 . 1 , SIP/2. 0/UDP 
scscf2 .home2 .net ;branch=z9hG4bK764z87 . 1, SIP/2 .0/UDP 
icscf2_s.home2 .net ;branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 
pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 
[5555 : : aaa :bbb : ccc : ddd] : 13 5 7 ; comp=sigcomp;branch=z9hG4bKnashds7 

Privacy: none 

From: <sip :userl_publicl®homel .net>; tag=171828 

To: <tel:+1212 5552222>;tag=31415 9;tag=31415 9 

Call -ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 127 INVITE 

Contact : <sip:user2_publicl@home2 .net ;gr=urn:uuid: 2ad8 950e-4 8a5-4a74-8d99- 
ad76cc7f c74 ; comp=sigcomp> ; +g . 3gpp . cs-voice , +g . 3gpp . cs-video 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, OPTIONS 

Server: PMI-0EA2, UCV-OD 

Content-Length: 



20. 200 (OK) response (P-CSCF#1 to CUA#1) - see example in table B.4.2-12 

P-CSCF#1 forwards the 200 (OK) response to the originating CUA. 

Table B.4.2-12: 200 (OK) response (P-CSCF#1 to CUA#1) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 :: aaa :bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

P-Asserted-Identity: < user2_publicl®home2 .net>, < tel : +12125552222> 

Privacy: 

From: 

To: 

Call-ID: 

CSeq: 

Require : 

Contact : 

Allow: 

Server : 

Content-Length : 



21. ACK request (CUA#1 to P-CSCF#1) - see example in table B.4.2-13 

The CUA responds to the 200 (OK) response with an ACK request sent to the P-CSCF#1. 

Table B.4.2-13: ACK request (CUA#1 to P-CSCF#1) 



ACK sip: <sip:user2_publicl@home2 . net ;gr=urn : uuid : 2ad8 95 0e-4 8a5-4a74-8d99- 
ad76cc7f c74 ;comp=sigcomp>; 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 70 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Route : <sip : pcscf 1 .visitedl .net : 7531; Ir ; comp=sigcomp> , <sip:scscfl .homel .net; lr>, 
<sip:scscf2 .home2 .net; lr>, <sip:pcscf2 . visited2 .net ; lr> 

From: <sip :userl_publicl@homel .net>; tag=17182 8 

To : <sip : user2_publicl@home2 . net> ; tag=314159 

Call -ID: Cb03a0s09a2sdfglkj4 90333 

Cseq: 127 ACK 

Content-Length: 



22. ACK request (P-CSCF#2 to CUA#2) - see example in table B.3.2-14. 

P-CSCF#2 forwards the ACK request to the terminating CUA. 
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Table B.3.2-14: ACK request (P-CSCF#2 to CUA#2) 



ACK sip: <sip: user2_publicl@home2 . net ; gr=urn : uuid : 2ad895 Oe-48a5 -4a74 - 8d99- 

ad76cc7f c74 ; comp=sigcomp> 
Via: SIP/2. 0/UDP pcscf 2 . visited2 . net : 5088 ; comp=sigcomp;branch=z9hG4bK361k21 . 1 , SIP/2. 0/UDP 

scscf2 .home2 .net ;branch=z9hG4bK764z87 . 1, SIP/2 .0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 

pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 

[5555 : : aaa :bbb: ccc :ddd] : 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 66 
From: 
To: 

Call-ID: 
Cseq: 
Content-Length : 



B.5 Signalling flows demonstrating capability information 
exchange in a CS call (only) 

B.5.1 Introduction 

This subclause provides signalling flows for exchange of information relevant for CSI in a CS call only. 

B.5.2 Establishing a CS call from a CSI capable UE 

Figure B.5. 2-1 shows the exchange of Radio Environment information, the IM Status, UE capability version and 
Personal ME Identifier by the CUAs of a CSI capable UE during a normal CS call establishment. 
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12. CONNECT ACKNOWLEDGE 



1 3. Active Call in CS domain 



Figure B.5.2-1 : CS call establishment (example of late assignment of user plane resources) 

The details of the signalhng flows are as follows:- 

1 . Initiation of CS call establishment with SETUP from originating side (from CUA#1 to MSC#1) 

CUA#1 starts the CS call towards CUA#2 sending out the SETUP. 

Specifically for CSI, the SETUP message includes:- 

Called Party Number = [(Numbering plan identifier = ISDN/telephony numbering plan), 

(type of number = international number ), (Number digits = 12125552222)] 
User-User IE = [((Protocol ID =3GPP capability exchange protocol), (Radio Environment = 1), 
(IM Status = IM subsystem capable and willing to register to IM subsystem), 
(Personal ME Identifier = 0007), (UE capability version = 04)]. 

2. CALL PROCEEDING (MSC#1 to CUA#1) 

MSC#1 after call processing checks replies to CUA#1 with CALL_PROCEEDING. 

MSC#1 progress with the CS Call by contacting MSC#2. Intermediate CS entities could be involved. 

The User-User information provided by CUA#1 is forwarded by MSC#1 towards MSC#2. 

There is no specific CSI information in CALL_PROCEEDING. 
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3. Initiation of CS terminating call with SETUP towards called party (from MSC#2 to CUA#2) 

MSC#2 starts the terminating call by initiating SETUP to CUA#2. 

Specifcally for CSI, the SETUP message includes:- 

Called Party Number = [(type of number = international number ), 

(Numbering plan identifier = ISDN/telephony numbering plan), (Number digits = 12125552222)] 

Calling Party Number = [(presentation indicator = Presentation allowed), 

(screening indicator = Network provided), (type of number = international number ), 
(Numbering plan identifier = ISDN/telephony numbering plan), (Number digits = 121255511 1 1)] 
User-User IE = [(Protocol ID =3GPP capability exchange protocol), (Radio Environment =1), 

(IM Status = IM subsystem capable and willing to register to IM subsystem), 

(Personal ME Identifier = 0007), (UE capability version = 04)]. 

The Personal ME Identifier provided by CUA#1 is later used by CUA#2 to relate to a particular terminal of 
CUA#1 that initiated this CS call is later progressed to a CSI call. 

4. CALL CONFIRM indicating terminating CS Call is being processed (from CUA#2 to MSC#2) 

CUA#2 on accepting the terminating call for further processing respond to MSC#2 with CALL_CONFIRM. 
There is no specific CSI information in CALL_CONFIRM. 

5. ALERTING indicating end user is alerted, (from CUA#2 to MSC#2) 

CUA#2 indicates locally to the user that a call has arrived by starting local alerting. With the call delivered, 

CUA#2 sends ALERTING to MSC#2. 

There are no CSI specifics in this message; in particular, there is no inclusion of User-User Information 

Element. 

NOTE: This example flow has taken to illustrate local alerting by CUA#2. This is the case if in the SETUP 
MSC#2 allows this to be done, as MSC intends to do a late assignment of user plane resources. 

6. ALERTING indicating far end alerting has started (from MSC#1 to CUA#1) 

Through Internediate CS entities, MSC#2 informs MSC#1 that the call has been delivered. 

MSC#1 sends to CUA#1 ALERTING indicating that call has been delivered and far end user is being alerted. 

Only local indication of call delivery can be provided by CUA#1 to the user (ie. ringing tone) as user plane 

resources have yet to be assigned by MSC#1. 

There are no CSI specifics in this message. 

7. CONNECT - far end user answers the call (from CUA#2 to MSC#2) 

When the user answers the call, CUA#2 sends CONNECT to MSC#2. 

Specifically for CSI, the CONNECT message includes:- 

User-User IE = [(Protocol ID =3GPP capability exchange protocol), (Radio Environment =1), 
(IM Status = IM subsystem capable and willing to register to IM subsystem), 
(Personal ME Identifier = 0EA2), (UE capability version = OD)]. 

After sending the CONNECT, CUA#2 is ready to connect to user plane resources and does the instance user 

plane resources is allocated. 

MSC#2 conveys call answer to MSC#1 and forwards any User-User information to MSC#1 that is included 

in the CONNECT from CUA#2. 

The provision of the Personal ME Identifier is to allow CUA#2 and CUA#1 to bind this CS Call answered by 

a particular terminal of CUA#2 to any eventual associated IM session to progress this CS call to a CSI call. 

8. Allocation of user plane resources 

MSC#2 has to allocate user plane resources to CUA#2 to allow speech to take place. In this example, this is 
the very latest point in time that MSC#2 can allocate such resources. This is referred to as Late Assignment. 
With the completion of the user plane resources, CUA#2 connects up and speech begins. 



£75/ 



3GPP TS 24.279 version 1 0.0.0 Release 1 51 ETSI TS 1 24 279 V1 0.0.0 (201 1 -03) 

9. CONNECT ACKNOWLEDGE (from MSC#2 to CUA#2) 

Upon completing Late Assignment, MSC#2 starts through connecting the call all the way from CUA#2 to the 
far end through the Intermediate CS Entities to MSC#L 

MSC#2 indicates this by sending CONNECT_ACKNOWLEDGE to CUA#2 and thus allowing CUA#2 to 
progress to active call state. 

10. Originating NW allocates user plane resources 

Knowing that the call has been answered, MSC#1 initiates allocation of user plane resources to originating 

CUA#1. 

In this example, this is the latest point in time that MSC#1 can assign the user plane resources for speech to 

take place. 

1 1 . CONNECT (from MSC#1 to CUA#1) 

MSC#1 indicates far end has answered the terminating call by sending CONNECT to CUA#1. MSC#1 

through connects the call on the network side and awaits CUA#1 to connect to the allocated user plane 

resources. 

Specifically for CSI, the CONNECT message includes: 

Connected Number = [(presentation indicator = Presentation allowed), 

(screening indicator = Network provided), (type of number = international number), 
(Numbering plan identifier = ISDN/telephony numbering plan), (Number digits = 12125552222)] 
User-User IE = [(Protocol ID =3GPP capability exchange protocol), (Radio Environment =1), 
(IM Status = IM subsystem capable and willing to register to IM subsystem), 
(Personal ME Identifier = 0EA2), (UE capability version = OD)]. 

12. CONNECT ACKNOWLEDGE (from CUA#1 to MSC#1) 

CUA#1 receiving CONNECT and with available user plane through connects the call and return 
CONNECT_ACKNOWLEDGE to MSC#1. The CONNECT ACKNOWLEDGE is to allow the network to 
progress to active call state. The CONNECT ACKNOWLEDGE does not have any CSI specifics. 

13. CS Call takes place 

The CS call takes place. 



B.6 Signalling flows demonstrating UE capability 
exchange with no UE capability version 

B.6.1 Introduction 

This subclause provides signalling flows for UE capability exchange with no UE capability version and no personal ME 
identifier outside a CS call or when a CS call is already in progress. 

B.6. 2 UE capability exchange outside a CS call 

Figure B. 6.2-1 shows the UE capability exchange using the OPTIONS method. 
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Figure B.6.2-1 : UE capability exchange before any CS call is established 

The details of the signalHng flows are as follows: 
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1. OPTIONS request (CUA#1 to P-CSCF#1) - see example in table B.6.2-1 

The originating CUA wants to know the capabilities of the terminating UE, preferably a UE that supports 
CS -voice and CS -video, or one or the other. 

Table B.6.2-1 : OPTIONS request (CUA#1 to P-CSCF#1) 



OPTIONS tel:+12125552222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max- Forwards : 70 

Route : <sip ipcscf 1 . visitedl .net : 7531; lr;comp=sigcomp>, <sip lorigOscscf 1 .homel .net ; lr> 

P-Pref erred-Identity : <tel : +l-212-555-llll> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=171828 

To: <tel:+12125552222> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 OPTIONS 

Require: sec -agree 

Proxy-Require: sec-agree 

Supported: gruu 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321; 

port-c=8642 ; port-s=7531 
Accept -Contact : * , +g. 3gpp . cs- voice, +g. 3gpp . cs -video /explicit 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, OPTIONS 
Accept: application/sdp 
Content-Length: 



2. OPTIONS request (S-CSCF#1 to I-CSCF#2) - see example in table B.6.2-2 

S-CSCF#1 forwards the OPTIONS request to the I-CSCF#2, after mapping the tel URI to a SIP-URL 

Table B.6.2-2: OPTIONS request (S-CSCF#1 to l-CSCF#2) 



OPTIONS sip:user2_publicl@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP scscfl . homel . net ;branch=z9hG4bK332b23 . 1 , SIP/2. 0/UDP 

pcscfl .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 

[5555 : : aaa :bbb : ccc :ddd] : 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 
Max-Forwards: 68 

Record- Route : <sip:scscfl .homel .net ; lr>, <sip : pcscfl .visitedl .net ; lr> 
P-Asserted- Identity : 

P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Supported: 
Accept-Contact : 
Allow: 
Accept : 
Content-Length: 



3. Routing decision based on caller preferences and callee capabilities 

The S-CSCF for CUA#2 uses caller preferences (information from the Accept-Contact header) and callee 
capabilities (information stored in the Registrar from the REGISTER Contact header) information to decide 
how to route the OPTIONS request. 

4. OPTIONS request (P-CSCF#2 to CUA#2) - see example in table B.6.2-4 

P-CSCF#2 forwards the OPTIONS request to the terminating CUA. 
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Table B.6.2-4: OPTIONS request (P-CSCF#2 to CUA#2) 



OPTIONS sip: [5555 : :eee: fff :aaa:bbb] : 8805;comp=sigcomp SIP/2.0 

Via: SIP/2. 0/UDP pcscf2 .visited2 .net :5088;comp=sigcomp;branch=z9hG4bK361k21.1, SIP/2. 0/UDP 

scscf2.home2 .net ;branch=z9hG4bK764z87 . 1, SIP/2 .0/UDP 

icscf2_s.home2 .net ;branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 

pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 

[5555 : : aaa :bbb: ccc :ddd] : 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 
Max-Forwards: 65 
Record- Route : <sip :pcscf 2 . visited2 .net : 5 088 ; lr;comp=sigcomp>, <sip:scscf2 .home2 .net ; lr>, 

<sip:scscfl .homel .net ; lr>, <sip : pcscf 1 .visitedl .net; lr> 
P-Asserted- Identity : 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Supported: 
Accept-Contact : 
Allow: 
Accept : 

Content-Length: 
P-Called-Party-ID: 



5. Save CUA#l"s address, prepare 200 OK response 

The terminating CUA caches any address related information it learns about CUA#1 from the OPTIONS 
request, such as its SIP URL The terminating CUA adds feature parameters to the Contact header field in the 
OPTIONS response indicating its capabilities. The feature parameters that were included in the registration 
generated by the terminating CUA are used in the OPTIONS response. 

6. 200 (OK) response (CUA#2 to P-CSCF#2) - see example in table B.6.2-6 

The terminating CUA sends a 200 (OK) response for the OPTIONS request containing the terminating 
CUA"s capabilities. This information is declared both in the media feature tags listed in the Contact header 
and in the SDP. In this example, CUA#2 declares capability for cs-voice, but not cs-video, and it declares 
support for MSRP, RTP video (H.263) and RTP audio (AMR). 
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Table B.6.2-6: 200 (OK) response (CUA#2 to P-CSCF#2) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net : 5088 ; comp=sigcomp;branch=z9hG4bK361k21 . 1 , SIP/2. 0/UDP 
scscf2 .home2 .net ;branch=z9hG4bK764z87 . 1, SIP/2 .0/UDP 
icscf2_s.home2 .net ;branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 
pcscfl.visitedl.net;branch=z9hG4bK24 0f34 .1, SIP/2 .0/UDP 
[5555 : :aaa:bbb:ccc:ddd] : 1357;comp=sigcomp;branch=z9hG4bKnashds7 

Record- Route : <sip : pcscf 2 . visited2 .net : 5088 ; lr;comp=sigcomp>>, <sip:scscf2 .home2 .net ; lr>, 
<sip:scscfl .homel .net ; lr>, <sip : pcscf 1 . visitedl .net ; lr> 

Privacy: none 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=123451D0FCEll 

From: <sip :userl_publicl@homel .net>; tag=171828 

To : <sip : user2_publicl@home2 . net> ; tag=314159 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 OPTIONS 

Supported: gruu, preconditions, lOOrel 

Contact : <sip:user2_publicl@home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d99- 
ad76cc7f c74 ;comp=sigcomp>; +g. 3gpp . cs- voice, <tel:+12125552222> 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, OPTIONS 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933617 IN IP6 5555:: eee : f f f : aaa : bbb 

s = - 

c = IN IP6 5555 : :eee:fff :aaa:bbb 

t = 

m=message TCP/MSRP * 

a=accept-types : text/plain text/html message/cpim image/ jpeg image/gif video/3gpp 

a=max-size : 65536 

m=video RTP/AVP 96 

a=rtpmap:96 H263-2000/90000 

m=audio RTP/AVP 97 

a=rtpmap:97 AMR/8000 

m=video RTP/AVPF 96 

a=rtpmap:96 H263-2000/90000 

m=audio RTP/AVPF 97 

a=rtpmap:97 AMR/8000 



SDP The SDP contains: 

The set of offered content types supported by UE#2 and desired by the user at UE#2 for an MSRP 
session in the accept-types attribute and indicates the maximum size message that can be received by 
UE#2 in the max-size attribute (no dynamically allocated attributes are included, for example, the a=path 
line is not there); 

The supported video codec and relevant parameters (but no dynamically allocated parameters); 

The supported audio codec and relevant parameters (but no dynamically allocated parameters). 

No ports are declared since UE capabilities are just being listed. 



7. 200 (OK) response (P-CSCF#1 to CUA#1) - see example in table B.6.2-7 

P-CSCF#1 forwards the 200 (OK) response to the originating CUA. 
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Table B.6.2-7: 200 (OK) response (P-CSCF#1 to CUA#1) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc :ddd] : 1357 ; comp = sigcomp;branch=z9hG4bKnashds7 

Record- Route : <sip ipcscf 2 . visited2 .net; lr>, <sip:scscf2 .home2 .net; lr>, 

<sip:scscfl .homel .net; lr>, <sip:pcscfl . visitedl .net : 7531; lr;comp=sigcomp> 
P-Asserted- Identity : 
Privacy: 
From: 
To: 

Call-ID: 
CSeq: 

Supported: 
Contact : 
Allow: 

Content-Type : 
Content-Length : 

v= 
o= 

s= 
c= 

t= 

m= 
a= 
a= 
m= 
a= 
m= 
a= 
m= 
a= 
m= 



8. Cache information on CUA#2"s capabilities 

Since no CS call is ongoing, cache the information obtained on CUA#2"s capabilities for later use within a CS 
call. 

9. OPTIONS request (CUA#2 to P-CSCF#2) - see example in table B.6.2-9 

The originating CUA wants to know the capabilities of the terminating UE, preferably a UE that supports cs- 
voice and cs -video, or one or the other. 

Table B.6.2-9: OPTIONS request (CUA#2 to P-CSCF#2) 



OPTIONS tel: +12125551111 SIP/2.0 

Via: SIP/2. 0/UDP [5555 :: eee : fff : aaa :bbb] : 8805 ; comp=sigcomp;branch=af 45K329 j std43 

Max- Forwards : 70 

Route : <sip :pcscf 2 . visited2 .net : 774 3 ; Ir ; comp=sigcomp> , <sip :orig@scscf 2 .home2 .net; lr> 

P- Preferred- Identity: <tel:+l-212-555-2222> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=123451D0FCEll 

Privacy: none 

From: <sip :user2_public2@home2 .net>; tag=1912031 

To: <tel:+12125552222> 

Call-ID: ast324c2ho9512go92 3 8ks4b 

Cseq: 127 OPTIONS 

Require: sec-agree 

Proxy-Require: sec-agree 

Supported: gruu 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-9S ; spi-c=23456789; spi-s=12345678 ; 

port-c=8318; port-s=7743 
Accept -Contact : * , +g. 3gpp . cs- voice, +g. 3gpp. cs- video; explicit 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, OPTIONS 
Accept: application/sdp 
Content-Length: 



10. OPTIONS request (S-CSCF#2 to I-CSCF#1) - see example in table B.6.2-10 

S-CSCF#2 forwards the OPTIONS request to the I-CSCF#1, after mapping the tel URI to a SIP-URI. 



£75/ 



3GPP TS 24.279 version 1 0.0.0 Release 1 57 ETSI TS 1 24 279 V1 0.0.0 (201 1 -03) 

Table B.6.2-10: OPTIONS request (S-CSCF#2 to l-CSCF#1) 



OPTIONS sip:userl_publicl@homel .net SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ;branch= af 45K329J sg213 , SIP/2. 0/UDP 
pcscf2 .visited2 .net;branch= af 45K329J sbbb2 , SIP/2. 0/UDP 
[5555: :eee: f f f :aaa:bbb] : 8805;comp=sigcomp;branch= af 45K329J std43 

Max- Forwards : 68 

Record- Route : <sip:scscf2 .home2 .net; lr>, <sip:pcscf2 . visited2 .net ; lr> 

P-Asserted- Identity : 

P-Charging-Vector : icid-value="H7a2rvdguTd6eYt7br=ac?+g5468HdrdRf 54b" ; orig-ioi=home2 .net 

Privacy: 

From: 

To: 

Call-ID: 

Cseq: 

Supported: 

Accept-Contact : 

Allow: 

Accept : 

Content-Length: 



1 1 . Routing decision based on caller preferences and callee capabilities 

The S-CSCF for CUA#1 uses caller preferences (information from the Accept-Contact header) and callee 
capabilities (information stored in the Registrar from the REGISTER Contact header) information to decide how 
to route the OPTIONS request. 

12. OPTIONS request (P-CSCF#1 to CUA#1) - see example in table B.6.2-12 

P-CSCF#1 forwards the OPTIONS request to the terminating CUA. 

Table B.6.2-12: OPTIONS request (P-CSCF#1 to CUA#1) 



OPTIONS sip: [5555 : :aaa:bbb:CCC:ddd] : 1357;comp = sigcomp SIP/2.0 

Via: SIP/2 . 0/UDP pcscfl. visitedl.net : 6809;comp=sigcomp;branch= af 45K329J sgf f f , SIP/2. 0/UDP 

scscf 1 .homel .net ;branch= af 45K329J sl234 , SIP/2. 0/UDP icscf l_s .homel .net ;branch= 

af45K329jsskit, SIP/2. 0/UDP scscf 2 . home2 . net ;branch= af 45K329J sg213 , SIP/2. 0/UDP 

pcscf2.visited2 .net;branch= af 45K329J sbbb2 , SIP/2. 0/UDP 
[5555: :eee: f f f :aaa:bbb] : 88 05 ; comp=sigcomp;branch= af 4 5K32 9J std4 3 
Max-Forwards: 65 
Record- Route : <sip : pcscfl . visitedl .net : 68 09; lr;comp=sigcomp>, <sip:scscfl .homel .net ; lr>, 

<sip:scscf2 .home2 .net ; lr>, <sip :pcscf 2 . visited2 .net; lr> 
P-Asserted- Identity : 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Supported: 
Accept-Contact : 
Allow: 
Accept : 

Content-Length: 
P- Called- Party- ID: 



13. Save CUA#l"s address, prepare 200 OK response 

The terminating CUA caches any address related information it learns about CUA#2 from the OPTIONS 
request, such as its SIP URL The terminating CUA adds feature parameters to the Contact header field in the 
OPTIONS response indicating its capabilities. The feature parameters that were included in the registration 
generated by the terminating CUA are used in the OPTIONS response. 

14. 200 (OK) response (CUA#1 to P-CSCF#1) - see example in table B.6.2-14 

The originating CUA sends a 200 (OK) response for the OPTIONS request containing the originating CUA"s 
capabilities. This information is declared both in the media feature tags listed in the Contact header and in the 
SDP. In this example, CUA#1 declares capability for cs-voice and cs-video, and it declares support for MSRP, 
RTP video (H.263) and RTP audio (AMR). 
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Table B.6.2-14: 200 (OK) response (CUA#1 to P-CSCF#1) 



SIP/2.0 200 OK 

Via: SIP/2 . 0/UDP pcscfl .visitedl .net : 6809;comp=sigcomp;branch= af 45K329J sgf f f , SIP/2. 0/UDP 

scscf 1 .homel .net;branch= af 45K329J sl234 , SIP/2. 0/UDP icscf l_s .homel .net ;branch= 

af45K329jsskit, SIP/2. 0/UDP scscf 2 .home2 .net ;branch= af 45K329J sg213 , SIP/2. 0/UDP 

pcscf2 .visited2 .net;branch= af 45K329J sbbb2 , SIP/2. 0/UDP 
[5555: :eee: f f f :aaa:bbb] : 8805 ; comp=sigcomp;branch= af 45K329J std43 
Record- Route : <sip : pcscfl .visitedl .net : 6809; lr;comp=sigcomp>, <sip:scscfl .homel .net ; lr>, 

<sip:scscf2 .home2 .net; lr>, <sip:pcscf2 . visited2 .net; lr> 
Privacy: none 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
From: <sip :userl_publicl®homel .net>; tag=171828 
To : <sip : user2_publicl@home2 . net> ; tag=314159 
Call -ID: ast324c2ho9512go92 3 8ks4b 
Cseq: 127 OPTIONS 

Supported; gruu, preconditions, lOOrel 
Contact : <sip : userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lldO-a765-OOaOc91e6bf 6 ; 

comp=sigcomp>; +g. 3gpp . cs-voice; +g. 3gpp . cs-video, <tel : +12125551111> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, OPTIONS 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933617 IN IP6 5555:: aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=message TCP/MSRP * 

a=accept-types : text/plain text/html message/cpim image/ jpeg image/gif video/3gpp 

a=max-size : 65536 

m=video RTP/AVP 96 

a=rtpmap:96 H263-2000/90000 

m=audio RTP/AVP 97 

a=rtpmap:97 AMR/8000 

m=video RTP/AVPF 96 

a=rtpmap:96 H263-2000/90000 

m=audio RTP/AVPF 97 

a=rtpmap:97 AMR/8000 



SDP The SDP contains: 

The set of offered content types supported by UE#1 and desired by the user at UE#1 for an MSRP 
session in the accept-types attribute and indicates the maximum size message that can be received by 
UE#1 in the max-size attribute (no dynamically allocated attributes are included, for example, the a=path 
line is not there); 

The supported video codec and relevant parameters (but no dynamically allocated parameters); 

The supported audio codec and relevant parameters (but no dynamically allocated parameters). 

No ports are declared since UE capabilities are just being listed. 



15. 200 (OK) response (P-CSCF#2 to CUA#2) - see example in table B.6.2-15 

P-CSCF#2 forwards the 200 (OK) response to the originating CUA. 
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Table B.6.2-15: 200 (OK) response (P-CSCF#2 to CUA#2) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 : : eee : f f f : aaa :bbb] : 8805 ; comp = sigcomp;branch=af 45K329 j std43 

Record- Route : <sip ipcscf 1 . visitedl .net : 6809; lr;comp=sigcomp>, <sip:scscfl .homel .net ; lr>, 

<sip:scscf2 .home2 .net; lr>, <sip:pcscf2 . visited2 .net; lr> 
P-Asserted- Identity : 
Privacy: 
From: 
To: 

Call-ID: 
CSeq: 

Supported: 
Contact : 
Allow: 

Content-Type : 
Content-Length : 

v= 
o= 

s= 
c= 

t= 

m= 
a= 
a= 
m= 
a= 
m= 
a= 



16. Cache information on CUA#l"s capabilities 

Since no CS call is ongoing, cache the information obtained on CUA#l"s capabilities for later use within a CS call. 

17. CS call establishment 

Either UE initiates the setup of a CS call between CUA#1 and CUA#2, as described in subclause B.5. However, in 
subclause B.5 UE capability version and personal ME identifier are used. 

B.6.3 UE capability exchange when a CS call is already in 
progress 

Figure B.6.3-1 shows the UE capability exchange using OPTIONS when a CS call is already in progress between 
CUA#1 and CUA#2. 
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Figure B.6.3-1 : UE capability exchange using OPTIONS after a CS call is established 
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Only the details of the signalling flows are described that are different from the flows where UE capability exchange 
happens before a CS call is established (see subclause B.6.2). 

1 . CS call establishment 

Either UE initiates the setup of a CS call between CUA#1 and CUA#2, as described in subclause B.5. In this 
example the UE capability version and personal ME identifier are not transferred as part of the CS call 
signalling. Therefore, CUA#1 is not aware of the capabilities of CUA#2 and starts a capability exchange. 

2. OPTIONS request (CUA#1 to P-CSCF#1) 

As the CS call is already established, the OPTIONS request is built using the tel URI that is the same as the 
connected number received in the Connect Message from the already established CS call. This assumes that 
CUA#1 originated the CS call. 

2. to 5. OPTIONS request (CUA#1 to CUA#2) 

Same as steps for OPTIONS when no CS call is established, see subclause B.6.2 steps 1 to 4. 

6. Cache information of CUA#l"s capabilities and display capabilities available during this CS call 

Since a CS call is ongoing, use the information in the OPTIONS request to indicate to the user which capabilities 
are available during this CS call. Also, cache the information about CUA#l"s capabilities for later use. 

7. to 8. 200 (OK) response to OPTIONS request (CUA#2 to CUA#1) 

Same as steps for OPTIONS when no CS call is established, see subclause B.6.2 steps 6 to 7. 

9. Cache information of UE#2"s capabiUties and display capabiUties available during this CS call 

Since a CS call is ongoing, use the information in the 200 (OK) response to the OPTIONS request to indicate to 
the user which capabilities are available during this CS call. Also, cache the information about UE#2"s 
capabilities for later use. 

10. OPTIONS request (CUA#2 to P-CSCF#2) 

When the CS call is already established, then the OPTIONS request is built using the tel URI that is the same as 
the calling number received in the SETUP Message from the already established CS call. 

10. to 13. OPTIONS request (CUA#2 to CUA#1) 

Same as steps for OPTIONS when no CS call is established, see subclause B.6.2 steps 9 to 12. 

14. Cache information of CUA#2"s capabilities and display capabiUties available during this CS call 

Since a CS call is ongoing, use the information in the OPTIONS request and if available previously stored 
capabilities of CUA#2 to indicate to the user which capabilities are available during this CS call. Also, cache the 
information about CUA#2"s capabilities for later use. 

15. to 16. 200 (OK) response to OPTIONS request (CUA#1 to CUA#2) 

Same as steps for OPTIONS when no CS call is established, see subclause B.6.2 steps 14. to 15. 

17. Cache information on UE#l"s capabiUties and display capabilities available during this CS call 

Since a CS call is ongoing, use the information in the 200 (OK) response to the OPTIONS request to indicate to the user 
which capabilities are available during this CS call. Also, cache the information obtained on UE#l"s capabilities for 
later use. 
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B.7 Signalling flows demonstrating UE capability 
exchange with UE capability version 

B.7.1 Introduction 

This subclause provides signalling flows for UE capability exchange with UE capability version and personal ME 
identifier outside a CS call or when a CS call is already in progress. 

B.7. 2 UE capability exchange with UE capability version 

Figure B.7. 2-1 shows the UE capability exchange using OPTIONS when an IM session or a CS call is already in 
progress between CUA#1 and CUA#2. In this figure, CUA#2 received UE capability version and personal ME 
identifier, which means for instance that CUA#l"s capabilities have been significantly updated. 

The difference between with no UE capability version (Figure B. 6.2-1, B.6.3-1) and with UE capability version (Figure 
B.7. 2-1) of UE capability exchange is that the frequency of OPTIONS transaction is reduced through exchange of UE 
capability version (Figure B.7. 2-1). 
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Figure B.7.2-1 : UE capability exchange using OPTIONS after receiving UE capability version during 

an IM session setup or a CS call setup 

If UE capability exchange performs after receiving UE capability version and personal ME identifier during an IM 
session setup, initial IM session setup messages are used as follows; 

1. INVITE request and 200 OK response 

la. INVITE request (CUA#1 to CUA#2) - see example in table B.7.2-la 

CUA#1 sends INVITE request with UE#l"s capability version to CUA#2. The UE#l"s capability version is set to 
a different value from the previously stored UE#l"s capability version, because the CUA#1 has updated its 
capability. 

Table B.7.2-1 a: INVITE request (CUA#1 to CUA#2) 



£75/ 



3GPP TS 24.279 version 10.0.0 Release 10 



64 



ETSI TS 124 279 VI 0.0.0 (2011-03) 



INVITE tel:+12125552222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max- Forwards : 70 

Route : <sip ipcscf 1 . visitedl .net : 7531; lr;comp=sigcomp>, <sip : origOscscf 1 .homel .net; lr> 

P- Preferred- Identity: <tel : +l-212-555-llll> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=171828 

To: <tel:+12125552222> 

Call -ID: Cb03a0s09a2sdfglkj4 90333 

Cseq: 127 INVITE 

Require: sec-agree 

Proxy-Require: sec-agree 

Supported: gruu 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-9S ; spi-c=987S5432 ; spi-s=87S54321; 
port-c=B642; port-s=7531 

Contact : <sip :userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6 ; comp=sigcomp> 

Accept -Contact : * , +g . 3gpp . cs -voice, +g. 3gpp . cs- video; explicit 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, OPTIONS 

Accept: application/sdp, application/3gpp-ims+xmlUser-Agent : PMI-0007, UCV-04 

Content-Length: { . . ) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=message 3402 TCP/MSRP * 

a=accept-types :message/cpim text/plain text/html image/ jpeg image/gif video/3gpp 

a=path:msrp: // [5555 : : aaa: bbb: ccc :ddd] : 34 02/slll2 71; tcp 

a=max-size : 131072 



lb. 200 OK response (CUA#2 to CUA#1) - see example in table B.7.2-lb 
CUA#2 accepts the session 

Table B.7.2-1b: 200 OK response (CUA#2 to CUA#1) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net : 5088 ; comp=sigcomp;branch=z9hG4bK361k21 . 1 , SIP/2. 0/UDP 
scscf2 .home2 .net ;branch=z9hG4bK764z87 . 1, SIP/2 .0/UDP 
icscf2_s.home2 .net ;branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP 
scscfl. homel. net ;branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 
pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 
[5555 : : aaa :bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=171828 

To: <tel:+1212 5552222>;tag=314159;tag=31415 9 

Call -ID: Cb03a0s0 9a2sdfglkj 490333 

Cseq: 127 INVITE 

Supported: gruu 

Contact : <sip: user2_publicl@home2 .net ;gr=urn:uuid: 2ad8950e-48a5-4a74-8d99- 
ad76cc7f c74 ; comp=sigcomp> ; +g . 3gpp . cs-voice , +g . 3gpp . cs-video 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, OPTIONS 

Server: PMI-0EA2, UCV-OD 

Content-Length: (...) 

v= 
o= 

s= 
c= 

t= 

m= 
a= 
a= 
a= 
a= 
a= 



If UE capability exchange performs after receiving UE capabiHty version during a CS call setup, initial CS call setup 
messages are used as follows; 

1'. SETUP request and CONNECT response 
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I'a. SETUP request (CUA#1 to CUA#2) 

CUA#1 send CS call SETUP message to CUA#2. The UE#l"s capability version is set to a different value from 
the previously stored UE#l"s capability version, because the CUA#1 has updated its capability. Specifically for 
CSI with UE capability version, the SETUP message includes; 

- Called Party Number = [(Numbering plan identifier = ISDN/telephony numbering plan), 

(type of number = international number), (Number digits = 12125552222)] 
User-User IE = [(Protocol ID =3GPP capability exchange protocol), (Radio Environment =1), 
(Personal ME Identifier = 0007), (UE Capability Version = 04)]. 

CUA#1 ensures that the Personal ME Identifier and UE capability version within the User-User IE of the SETUP 
correlates to the Personal ME Identifier and UE capability version used by CUA#1 in the preceding IM session. 

I'b. CONNECT response (CUA#2 to CUA#1) 

CUA#2 send CS call CONNECT message to CUA#1 to estabhsh CS bearer. Specifically for CSI with UE 
capability version, the CONNECT message includes; 

- User-User IE = [(Protocol ID =3GPP capability exchange protocol), (Radio Environment =1), (Personal ME 
Identifier = 0EA2), (UE Capability Version = OD)]. 

CUA#2 uses the Personal ME Identifier and UE capability version provided by CUA#1 in SETUP to bind the 
IM session to this CS Call. CUA#2 returns the Personal ME Identifier and UE capability version provided by 
CUA#2 within the User-User IE. 

2. CUA#2 decide whether to send OPTIONS request according to UE#l"s capability version 

CUA#2 decides whether to send SIP OPTIONS request to CUA#1 according to UE capability version received 
during the IM session setup. If the received UE capability version is set differently from previously stored UE 
capability version, it means that CUA#1 has updated its capabilities. In this case, CUA#2 sends SIP OPTIONS 
request to CUA#1 to get CUA#l"s updated capability information. 

3 to 6. OPTIONS request (CUA#2 to CUA#1) 

Same as steps for OPTIONS when IM session is established, see subclause B.6.2 steps 9. to 12. 

7. Store CUA#2"s address information and display capabiUties, which have been updated available during this 
IM session 

Since an IM session is ongoing, use the information in the SIP OPTIONS request to indicate to the user which 
capabilities are available during this IM session. Also, store the address information and capabilities from 
CUA#2 for later use. 

8. to 10. 200 (OK) response to OPTIONS request (CUA#1 to CUA#2) 

Same as steps for OPTIONS when IM session with no UE capability version is established, see subclause B.6.2 
steps 14. to 15. 

11. Store information on CUA#l"s capabiUties 

Since an IM session is ongoing, use the information in the 200 (OK) response to the OPTIONS request to 
indicate to the user which capabilities are available during this IM session. Also, store the capability information 
from CUA#1 for later use. 
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B.8 Signalling flows demonstrating an IMS multimedia 
session setup with IMS origination and CSI 
termination. 

B.8.1 Introduction 

This subclause provides signalling flows for establishing an IM multimedia session with IMS origination and CSI 
termination. 

The flows shows some additions related to CSI. The B2B CUA of the CSI AS includes the media feature tags 
g.3gpp.cs-voice and g.3gpp.cs-video in the Accept-Contact header and in the Contact header. 

UE#1 illustrated in the figures is a UE that originates multimedia sessions without involving the CS domain for media 
transport. 

B.8. 2 CSI interworking function establishing a combinational CS 
call and an IMS session to a terminating UE 

Figure B. 8.2-1 illustrates an example signalling flow for an IMS originated multimedia session (with real time voice 
component and a non-real time messaging component) a CSI UE interworked by the CSI interworking function in the 
IM CN subsystem. 

In this example the messaging component is transported by MSRP. 

In this example, UE#1 needs to reserve local resources. 

In this example, the "100 Trying" in response to an initial INVITE and other SIP message exchanges, eg. the 183 
Session Progress from CUA#2 and PRACK going to CUA#2, are not shown for simplicity. 

In this example, the originating NW and the terminating NW are shown as two separate NWs. This does not imply that 
the originating and terminating cannot be just one NW. What this example is meant to illustrate is which part of the NW 
(originating or terminating) that the CSI AS for terminating session handling is invoked. 

In this example the CSI AS in its 183 Session Progress to UE#1 provides an SDP answer wherein the audio component 
indicates a "c=" line destination pointing to the MGW and for the MSRP component the "c=" line at session level 
indicates the destination as the terminating CUA itself. 
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Figure B/8.2-1 : Interworking an originating multimedia IIVIS session to a CSI UE 
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Figure B/8.2-1 (continued): Interworking an originating multimedia IIVIS session to a OS! UE 
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1. SIP INVITE request (from originating UE#1) 

UE#1 wants to initiate a multimedia session with the terminating CUA#2 and sends out an INVITE request. 
See example in Table B.8.2-1. 



Table B.8.2-1: INVITE request (UE#1 to P-CSCF#1) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max- Forwards : 7 

Route : sip ipcscf 1 .homel .net : 7531; lr;comp=sigcomp>, <sip lorigOscscf 1 .homel .net ; lr> 

P-Pref erred-Identity : "Joe Bloke" <sip :user3_publicl@homel .net> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: <tel: +l-212-555-3333>; tag=171828 

To: <tel:+l-212-555-2222> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Supported: lOOrel; precondition, gruu 

Require: sec-agree 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; sp i= 8765432 1 ; portl = 7531 

Contact: < sip: userl_publicl@homel . net ;gr=urn : uuid : f 81d4f ae-7dec-lldO-a765- 

00a0c91e6bf 6 ;comp=sigcomp > 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATEAccept : application/sdp , application/3gpp-ims+xml 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96a=tcap:l RTP/AVPF 

a=pcfg:l t=l 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv a=inactive 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 2 

m=message 3402 TCP/MSRP 

a=accept-types :message/cpim text/plain text/html image/ jpeg image/gif video/3gpp 

a=path:msrp: // [5555 : : aaa: bbb: ccc :ddd] : 34 02/slll2 71; tcp 

a=max-size : 131072 



2. SIP INVITE request (from originating intermediate IM CN subsystem #1 to the terminating IM CN 
subsystem #2) 

The originating IM CN #1 maps the Tel URI to a SIP URI and forwards the INVITE request towards the 
terminating IM CN #2. See example in Table B.8.2.-2 
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Table B.8.2-2: INVITE request (S-CSCF#1 to S-CSCF#2) 



INVITE <sip:user2_public2@home2 .net> SIP/2.0 

Via: SIP/2. 0/UDP scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2. 0/UDP 
pcscf 1 . homel . net ;branch=z9hG4bK240f 34 . 1 , SIP/2 . 0/UDP 
[5555 : : aaa : bbb : ccc :ddd] : 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 67 

Route : <sip : as .homel .net; lr>, <sip : Cb03a0s09a2sdfglkj490333@scscf 1 .homel .net ; lr> 
Record-Route: <sip : scscfl .homel .net>, <sip :pcscfl .homel .net> 

P-Asserted-Identity : "Joe Bloke" <sip :user3_publicl@homel .net>, <tel: +l-212-555-333> 
P-Access-Network-Inf o : 
Privacy: none 
P-Charging-Vector : 

P- Charging- Function-Addresses : ccf=[5555::b99:c88:d77:e66]; ccf=[5555::a5 5:b44:c33:d22] 
ecf= [555 5 : :lff :2ee:3dd:4ee] ; ecf = [5555 : : 6aa : 7bb : 8cc : 9dd] 
From: 
To: 

Call-ID: 
Cseq: 127 
Supported: 
Contact : 
Allow: 

Content-Type : 
Content-Length: (...) 

v=0 
o= 
s= 
c= 

t= 

m= 
a= 
a= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
m= 
a= 
a= 
a= 



2a. Evaluation of initial filter criteria (at S-CSCF#2) 

The S-CSCF#2 performs iFC evalutation in order to decide what services to invoke and how to route the 
INVITE request. In this example, the S-CSCF#2 determines that the INVITE request must be routed to the CSI 
AS. 

3. SIP INVITE request (to the target CSI application server) 

S-CSCF#2 routes the INVITE to the indicated CSI application server. See example in Table B.8.2-3. 
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Table B.8.2-3 INVITE request (S-CSCF#2 to CSI application server) 



INVITE <sip:user2_public2@home2 .net> SIP/2.0 

Via: SIP/2. 0/UDP scscf2 .home2 .net;branch=y2y2y2y2y2y2y2 .2, 
SIP/2 .0/UDP scscfl.homel.net;branch=z9hG4bK332b23 .1, 
SIP/2 .0/UDP pcscfl.homel.net;branch=z9hG4bK240f34 .1, SIP/2 . 0/UDP 
[5555 : : aaa : bbb : ccc :ddd] : 1357;comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 66 

Route : <sip : as .homel .net ; lr>, <sip : Cb03a0s0 9a2sdfglkj490333®scscf 1 .homel .net ; lr> 

Record-Route : <sip : scscf 2 . home2 . net> , 
<sip: scscf 1 .homel .net>, 
<sip:pcscf 1 .homel .net> 

P-Asserted-Identity : "Joe Bloke" <sip :user3_publicl@homel .net> 

P-Access-Network-Info : 

Privacy: none 

P-Charging-Vector : 

P- Charging- Function-Addresses : ccf=[5555::b99:c88:d77:e6 6]; ccf=[5555::a5 5:b44:c33:d22] 

ecf= [5555 : : If f : 2ee : 3dd : 4ee] ; ecf = [5555 : : 6aa : 7bb : 8cc : 9dd] 

From: 

To: 

Call-ID: 

Cseq: 127 

Supported: 

Contact : 

Allow: 

Content-Type : 

Content-Length: (...) 

v=0 

o= 

s= 

c= 

t= 

m= 
a= 
a= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
m= 
a= 
a= 



4. Termination logic processing by the CSI AS 

The CSI application server invokes its termination logic and based on the requested media components it decides 
to do a session split, i.e. to terminate the voice component via the CS domain and the session containing MSRP 
stream via an IP-CAN. 

NOTE 1: For splitting the session into two parts, the CSI AS will later initiate two INVITE requests: one in step 5 
for the MSRP component and another in step 7 for the voice component. The sequence of these INVITE 
requests is implementation specific (although this example shows first the INVITE for the voice 
component). 

NOTE 2: The two sessions (for the voice and session containing MSRP stream) are presented to the user as a single 
composite session. 



5. SIP INVITE request (from CSI AS to terminating user CUA#2 in the IM CN subsystem ) 

The CSI AS (acting as a B2B UA) initiates an INVITE request for the session containing the MRSP stream to 
the terminating CUA#2 with the Request URI set to the SIP URI received in the initial INVITE request received 
at step 3. See example in Table B. 8.2-4 
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Table B.8.2-4: INVITE request (CSI AS as B2BUA to S-CSCF#2 for IMS session) 



INVITE sip:user2_public2@home2 .net SIP/2.0 
Via: SIP/2. 0/UDP as.home2.net 
Max- Forwards : 7 
Route : 

Record-Route : <sip : as . home2 . net ; lr> 
P-Asserted-Identity: <tel: +l-212-555-3333> 
P-Access-Network-Info : 
P-Charging-Vector : 
Privacy: none 
Supported: gruu 

From: <tel: +l-212-555-3333>; tag=171828 
To: <tel:+l-212-555-2222> 
Call -ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 127 INVITE 

Contact : <sip :userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6 ; comp=sigcomp> 

Accept - Contact : * , +g . 3gpp . cs-voice , +g. 3gpp . cs-video;explicit 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=message 34 02 TCP/MSRP 

a=accept-types :message/cpim text/plain text/html image/jpeg image/gif video/3gpp 

a=path:msrp: // [5555 : : aaa: bbb: ccc :ddd] : 34 02/slll2 71; tcp 

a=max-size : 131072 



6. Reserve IP-CAN bearer for Media at terminating side 

The terminating CUA initiates media reservation. 

7. SIP INVITE request (from CSI AS to the terminating user CUA#2 in CS domain) 

Acting again as a B2B UA the CSI AS substitutes the SIP URI in the Request URI (received in step 3) with a 
Tel URI and initiates a new INVITE request. See example in Table B.8.2-5. 

Table B.8.2-5: INVITE request (CSI AS as B2BUA to S-CSCF#2 for CS call) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2.0 as.home.net; branch=z9hG4bKnashdt8t8 
Max-Forwards: 65 

Route: <sip : scscf 2 .home2 .net>, <sip :bgcf .home2 .net> 
Record-Route: <sip : as .home2 .net> 
P-Asserted-Identity: <tel: +l-212-555-3333> 
P-Access-Network-Info : 
Privacy: none 

From: <tel: +l-212-555-3333>; tag=171828 
To: <tel:+l-212-555-2222> 
Call -ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 127 INVITE 

Supported: lOOrel, precondition, gruu 
Require: sec-agree 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; sp i= 8765432 1 ; portl = 7531 
Contact : < sip :userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6 ;comp=sigcomp > 

Accept-Contact : *, +g . 3gpp . cs-voice , +g. 3gpp. cs-video;explicit 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96a=tcap:l RTP/AVPF 

a=pcfg:l t=l 
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b=AS : 25 . 4a=curr :qos local sendrecva=curr :qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv a=inactive 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2 , 5, 7; mode-change-period=2 

a = r tpmap :96 telephone- event 

a=maxptime : 2 



8. ISUP lAM (from the MGCF to the VMSC of the terminating CUA#2) 

The MGCF performs the IMS/CS interworking functions and initiates an ISUP lAM towards the VMSC. 
Because the media for the originating side is not yet available, the MGCF indicates "Continuity check performed 
on previous circuit" in the lAM. 

9. H248 interactions (between MGCF and MGW) 

MGCF interacts with MGW for necessary resource allocation. 

10. SIP 200 (OK) response (from CUA#2 back to CSI AS through intermediate IM CN subsystem #2) 

After reserving an IP-CAN bearer for the message session media component the terminating CUA sends a 200 
(OK) response for the INVITE request containing SDP that indicates that the terminating CUA has accepted the 
message session and listens on the MSRP TCP port returned in the path attribute in the answer for a TCP SETUP 
from the originating CUA. 

CUA#2 declares support only for CS-voice, not CS-video in its Contact header. The terminating CUA includes 
its personal ME identifier and UE capability version in the service header. 

See example in Table B.8.2-6. 

Table B.8.2-6: 200 (OK) response (CUA#2 to P-CSCF#2) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net : 5088 ; comp=sigcomp;branch=z9hG4bK361k21 . 1 , SIP/2. 0/UDP 
scscf2 .home2 .net ;branch=z9hG4bK764z87 . 1, SIP/2 .0/UDP 

Record- Route : <sip :pcscf 2 . visited2 .net : 50 8 8 ; Ir ; comp=sigcomp>> , <sip:scscf2 .home2 .net; lr>, 

Privacy: none 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

From: <tel: +l-212-555-3333>; tag=171828 

To: <tel:+l-212-555-2222>;tag=314159 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Supported: gruu 

Contact : <sip:user2_publicl@home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d99- 
ad76cc7f c74 ; comp=sigcomp> ; +g . 3gpp . cs-voice 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, OPTIONS 

Server: PMI-0EA2, UCV-08 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933617 IN IP6 5555:: eee : f f f : aaa : bbb 

s = - 

c = IN IP6 5555 : :eee:fff :aaa:bbb 

t = 

m=message 3402 TCP/MSRP * 

a=accept-types : text/plain text/html message/cpim 

a=path:msrp:// [5555: : eee : f f f : aaa :bbb] : 34 02/s2 3416 7; tcp 

a=max-size : 65536 



NOTE: The SDP contains the set of offered content types supported by CUA#2 and desired by the user at CUA#2 
for this session in the accept-types attribute and indicates the maximum size message that can be received 
by CUA#2 in the max-size attribute. 

11. SIP ACK request (CSI AS back to CUA#2) 

The CSI AS provides SIP ACK request to CUA#2. 

12. SIP 183 (Session Progress) response (from MGCF to CSI AS through intermediate IM CN subsystem #2) 
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The MGCF provides a 183 Session Progress request back to the CSI AS through S-CSCF#2. 
12a. SIP 183 (Session Progress) response (from CSI AS to UE#1) 

The CSI AS provides a 183 Session Progress response back to the UE#1. 

12a. SIP 183 (Session Progress) response (from CSI AS to UE#lthrough intermediate IM CN subsystems) 

CSI AS in turn provides 183 (Session Progress) response back to UE#1 through the intermediate IM CN 
subsystems. This 183 (Session progress) response from the CSI AS will include a SDP answer to UE#rs SDP 
offer in the initial INVITE. See example in Table B.8.2-7. 
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Table B.8.2-7: 183 (Session Progress) response (CSI AS to S-CSCF#2) 



SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP scscf2.home2 .net;branch=z9hG4bK764z87.1, 
SIP/2 .0/UDP icscf2_s.home2 .net ;branch=z9hG4bK871yl2 .1, 
SIP/2 . 0/UDP scscfl.homel.net;branch=z9hG4bK332b23 .1, 
SIP/2 . 0/UDP pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, 
SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Record- Route : <sip : pcscf 2 . visited2 .net : 5088 ; lr;comp=sigcomp>>, <sip:scscf2 .home2 .net ; lr>, 

Privacy: none 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

From: <tel: +l-212-555-3333>; tag=171828 

To: <tel:+l-212-555-2222> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Require: precondition, lOOrel 

Contact : <sip:user2_publicl@home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d99- 
ad76cc7f c74 ; comp=sigcomp> ; +g . 3gpp . cs-voice 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, OPTIONS 

Server: PMI-0EA2, UCV-0 8 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933617 IN IP6 5555:: eee : f f f : aaa : bbb 

s = - 

c=IN IP6 5555:: eee : f f f : aaa : bbb 

t = 

m=audio 3456 RTP/AVPF 97 96 

a=acfg:l t=l 

b=AS:25 .4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2 , 5, 7; mode-change-period=2 

a = r tpmap :96 telephone- event 

a=maxptime : 2 

c=IN IP6 5555 :: eee : fff :www:yyy 

t = 

m=message 3402 TCP/MSRP * 

a=accept-types : text/plain text/html message/cpim 

a=path:msrp:// [5555: : eee : fff : aaa : bbb] : 3402/s234167 ; tcp 

a=max-size : 65536 



13, 13a. SIP PRACK request (from UE#1) 

UE#1 upon receipt of 183 (Session Progress) response replies back with PRACK request. With that UE#1 
initiates resource allocation for the session it originated. 

14 Reserve IP-CAN bearer for Media at originating side 

The originating UE starts resource reservation for media bearers. 
15, 15a. SIP PRACK request (from CSI AS to MGCF) 

The PRACK from UE#1 lead the CSI AS to provide PRACK to the MGCF 
16,16a SIP 200 (OK) response (MGCF to CSI AS ) 

MGCF acknowledges the PRACK (from CSI AS) with 200 (OK) (back to CSI AS) 
17, 17a. SIP 200 (OK) response (from CSI AS to UE#1 through intermediate IM CN subsystems) 

CSI AS correspondingly provides the 200 (OK) back to UE#1 through the intermediate IM CN subsystems. 
18, 18a SIP UPDATE request (from UE#1 to CSI AS through intermediate IM CN subsystems) 

UE#1 indicates it has available the necessary resources. 
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19, 19a SIP UPDATE request (from CSI AS to MGCF through intermediate IM CN subsystem*!) 

CSI AS provides the indication of available resources at originating side to the MGCF. 

20. ISUP COT (from MGCF to VMSC) 

With the UPDATE indicating that originating side has the necessary media resources and as such conditions are 
met, the MGCF sends COT to the VMSC indicating "continuity check successful". 

21. SETUP (from VMSC to CUA#2) 

The VMSC now sends the SETUP towards the terminating CUA#2. 

22. CALL CONFIRM (from CUA#2 to VMSC) 

The terminating UE acknowledges and confirms acceptance of the incoming call by sending CONFRIM back to 
the VMSC. 

NOTE: There is no suggestion, by this example or otherwise, that CUA#2 only response with CALL CONFIRM 
after the INVITE for the IM CN subsystem is received. 

23. ALERTING (from CUA#2 to VMSC) 

For this example, the VMSC allows early local alerting. With the generation of local alerting, ALERTING is 
sent back from the UE to the VMSC. 

24. ACM, CPG, SIP 180 (Ringing) response and SIP Prack request (VMSC to MGCF through IM CN Subsystem 
to originating end) 

On receipt of the ALERTING from the terminating UE, the VMSC, MGCF, IM CN subsystem and the 
originating UE exchange ISUP and SIP signalling to indicate that the called party confirmed the call and did start 
ringing the end user. 

25. 25a . Resource allocation (VMSC to terminating UE, MGW and VMCS) 

The VMSC starts resource allocation towards the terminating UE. 
Between VMSC and the MGW resource allocation is also started. 

26. CONNECT (from CUA#2 toVMSC) 

When the user answers the call, the terminating UE sends CONNECT to the VMSC. After sending the 
CONNECT, the terminating UE is ready to connect to user plane resources. 

27. CONNECT ACK (from VMCS to CUA#2) 

VMSC connects up the user plane and return CONNECT_ACKNOWLEDGE to the terminating UE.. 
Through connect all the way back to originating UE is not initiated. 

28. ANM (from VMSC to MGCF) 

The VMSC having through connected the user plane sends an indication of answer to the MGCF. This is the 
ISUP ANM message. 

29. SIP 200 (OK) response (from MGCF to the CSI AS via the intermediate IM CN subsystem #2) 

Upon the receipt of the ANM from the VMSC, and after the connection of the media flow, the MGCF sends the 
SIP 200 (OK) final response to the received SIP INVITE request (in step 5) back to the CSI AS via the 
intermediate IM CN subsystem #2. 

30. 30a . SIP 200 (OK) response (from CSI AS to intermediate IM CN subsystem #2) 

The SIP 200 (OK) final response is provided by the CSI AS back to the originating UE#1 through the 
terminating intermediate IM CN subsystem #2. 
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NOTE: In this example, the CSI AS provides the 200 (OK) response back to the originating UE#1 after both the 
voice session and the session containing the MRSP have been successful established. 

31, 31a. SIP ACK (from UE#1 to CSI AS through intermediate IM CN subsystems) 

UE#1 responds to the 200 (OK) with ACK 

32, 32a. SIP ACK (CSI AS to MGCF) 

The CSI AS correspondingly provides the ACK to the MGCF. 
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